SOME CONCERNS WITH THE IXI PRODUCTION SERVICE Stockholm, August 7 1992 This is may personal thinking after having read the announcement of the RARE signing of the framework contract for the IXI Production Service with emphasis on the IP part of the described service. Bernhard Stockman 1. Background The RARE Executive Committee (REC) recently signed a framework contract with the nominated provider of the IXI Production Service, the follow-up of the COSINE IXI Pilot Service. This contract is not economically binding but states the conditions for provision of the service in terms of availability, speeds, costs etc. The actual signing of an economically binding IXI Production Service has to be done separately by each country interested in this service as there is today no pan-European legal entity that would sign such a contract on behalf of all nations involved. Initially a 2 Mbps X.25 service was proposed under the name TRIXI later renamed to EMPP (The European 2 Mbps Multiprotocol Pilot). The EMPP has now been renamed to EMPS (European MultiProtocol Service). The intention seems to be that the EMPS shall be the pilot phase of the IXI Production Service. (One can of course question the need for a pilot in something named a "production" service). During the the first year(s) of specification work to define the requirements in the call for tender of the IXI Production Service, the Internet Protocol (IP) was never included. Recently IP was added as a necessary requirement. The following evaluations of the biddings to the IXI Production Service and nomination of a winner was performed behind closed doors. Especially there was no consultation of RIPE, the European IP coordination activity. Through its meetings and information exchange activities, RIPE has created a wealth of technical expertise and experience in building large scale international IP networks. This European pool of knowledge and experience was completely ignored. This in spite of IP now was an integral part of the requested service. Some European IP experts was finally invited in June this year, i.e. when the service provider already had been chosen. Not to get informed on the details of the IP service implementation as this was still confidential but to help in specifying the pilot of the IP part of the EMPS. This specification had to be finalised within a short time after the IP experts were consulted, being part of the contract to be signed. Consequently there was no time for reflections and discussions. 2. Choice of Technology The implementation of the IP part of the service will be based on X.25 switches with some kind of IP router built-in. It is today unknown which kind of technology has been chosen to implement the IP service. It may be the case that the switch vendor tries to make a "quick and dirty" implementation of the IP service using some PC clone equipped with "gated", a public domain software. It should be emphasised that the IP routing technology and routing models supported has a big impact on the total European Internet and its possibility of efficient and stable connectivity to the global Internet. 3. Performance of the IXI Production Service As one intention with TRIXI, EMPP, EMPS and now the IXI Production Service is to build a 2 Mbps pan-European backbone, the performance at this bandwidth is of course interesting. At 2 Mbps the IP performance is initially 16 percent i.e around 300 Kbps and later to be improved to 21 percent of the 2 Mbps full capacity in 1993. This at an average packet size of 128 bytes. A performance table of the IXI Production Service (Note: 2 Mbps is not actually delivered by the PTT's but 1984 Kbps, 64 Kbps is used for signaling internal to the PTT network). From the Contract | Deduced | nom. packet start '93 | start '93 full start '93 kbit/s size % % | kbit/s kbit/s pkt/s pkt/s pkt/s | 64 128 90 90 | 58 58 62 56 56 64 1024 95 95 | 61 61 8 7 7 | 1984 128 16 21 | 317 417 1938 310 407 1984 512 64 85 | 1270 1686 484 310 412 1984 1024 95 95 | 1885 1885 242 230 230 This is very rough not counting link level overhead etc. The "full pkt/s"-column above shows the needed packet forwarding rate for a full utilization of the available bandwidth. The IXI Production Service will thus deliver a packet forwarding rate of around 300 packets per second today with a promised upgrade to around 400 packets per second 1993. This must be very cheap to have a chance on the market. (Using today off-the-shelf IP routing technology it is possible to achieve a forwarding rate of 20000 - 30000 packets per second between any two interfaces). It should be requested that the IXI Production Service provider shows a growth path consistent with expected performance needs. The quoted performance figures for the IXI Production service so far indicate a packet switching capacity per customer connection to be in the order of 300 pkt/s initially. This seems quite low for current needs already. See the appendix for a calculation of average packet sizes in an Internet network. 4. Interoperability Questions like interoperability with the 1000's of networks in the global Internet is not mentioned. Urgent subjects in the Internet like the need for sourced based routing, the need for support of the CIDR/supernetting according to current recommendations to cope with the growth of the routing tables, etc. is never described. The router implementation is stated to support EGP starting in October this year and BGP later. What BGP version to be supported is not mentioned. Support for BGP-III will be needed today to meet the requirements for dynamic and fast converging policy based routing. Support for BGP-4/IDRP and by that the supernetting in the very near future will be essential judging from the estimated growth rate of the today Internets to cope with these problems. Which kind of internal routing protocol that will be used and if this interacts sufficiently well with the exterior routing protocols is never mentioned. There exist no officially available interoperability tests of the chosen technology for the IP part of the IXI Production Service. Compare with other vendors who take pride in bringing their products to the Interop's to show their equipment can interoperate in the Internet environment. Nothing like that seems to have happened here but the choice of technology has been kept secret. It should thus be requested by the IXI Production Service provider that the technology used is revealed and independently tested. There are independent tests conducted regularly and widely published both on the networks and in the trade press. It should be requested that the IXI Production Service provider has coordinated routing with the rest of the European and Global Internet. Evidence of this would be a statement by the RIPE routing WG to the effect that it is expected to work. It should be requested that the IXI Production Service provider shows in depth understanding of ROAD issues and is likely to provide routing technologies to support CIDR and "real" policy based routing. i.m.h.o. this means source based routing and BGP-III initially and BGP-IV soon. It could here also be noted that the IXI Production Service provider have obviously assumed that there will be no transit across a region to somewhere else in the world, not connected to them directly. This is in reality probably an unvalid assumption. 5. Support for Common Network Management Interface. In the Internet environment a protocol for common network management has been specified, named SNMP. This protocol is today widely deployed and supported of 100's of vendors equipment. The IXI Production Service does not mention support of SNMP. 6. Cost Efficiency of the IXI Production Service It would be very informative to see the actual prices of the offered service but they are confidential and by that makes an open debate of the cost-efficiency of the proposed service impossible. The prices has been disclosed to RARE CoA members which thus will have the possibility of doing necessary cost-efficiency calculations. The IXI Production Service prices are based on the assumption that at least 75 64 Kbps access point equivalents will be contracted where a 64 Kbps access point counts as 1 and a 2 Mbps access points counts as 11.4. If it turns out that there is not enough 64 Kbps equivalents sold, the price offer will not be valid. Networks in Europe have already signaled that they will not sign the IXI Production Service before proven that it can deliver at least the same IP service efficiency and performance as compared to the EBONE. 7. Pilot Results Questionable. The contract states a 9 month pilot of the IP service. This pilot may give a correct indication if done in a realistic way. However, only those who actually subscribe and pay for the service will be eligible to participate in the pilot, at least during the first 4 months. Organizations that might be reluctant to spend money on an unproven service, not signing the service contract, will not be allowed to participate. This makes any positive results of the pilot highly questionable because pilot participants will not be interested to reveal that they have subscribed to and paid for a bad service. 8. Near Future Networking Requirements Today we see pilots of 34 Mbps WAN in various parts of Europe. Applications like multimedia mail, audio and video multicast are being tested on the production backbones. There will certainly be a need for upgrade of production services to these capacities in the near future to cope with the current development. Such pilot services should be done in close collaboration with deployed production backbones for easy migration to production status when ready and needed. Any production service contracted now needs to have demonstrated growth path to this performance bracket. Otherwise the European R&D community will again loose years and resources in a change of technology. 9. Conclusions Due to the current growth of the Internet it will probably be impossible to specify the service well enough to ensure it is useful to the community if the supplier provides just the specified service. It must be shown that they are willing and capable to adjust to changing needs. The EBONE Routing Specification has already changed several times during the lifetime of EBONE due to unforeseen growth rates and new technologies becoming available. A pure service contract is not the right structure for such a project. The administrative community must understand that the technical community is working hard to simplify the European Internet structure to the point where it remains manageable given the expected growth rates. This will only work if there is very close cooperation among all service providers at the technical level and the specifications remain flexible enough to make the necessary changes to keep it working. Any service provider who does not cooperate closely with all the others on the technical level and is not flexible to react to changing technical requirements is not only a nuisance but a danger to the whole community. Thus the administrative structures must allow for such cooperation and flexibility. If they do not, they must be considered harmful to the community. What the provider of the IXI Production Service has proposed as an alternative to the current EBONE IP service is an inferior technology in terms of efficiency and absolute performance with no guarantee of interoperability with the rest of the Internet. All too often we are using very much non-optimal technical solutions because of an administrative model that is very in-flexible in its realization of the rapid growth/change of of the technology needed. IP and it's needs are changing extremely fast right now, perhaps more than ever before. People in the Internet community are working hard to get new and dynamic solutions available. Europe must and has to stay at the leading edge of this. If we don't we are in danger of loosing the collaboration already built. Coordination of IP networking in Europe have so far been managed pretty well. RIPE has helped enormously in this regard as has the advent of EBONE and the way it is being driven at the operational, technical and management level. Due to complex policy requirements in European networking EBONE has today one of the worlds most advanced implementations of policy based routing. This could not have been achieved without close cooperation among the leading European experts in this field. My personal hope is that EBONE will continue and evolve and that the Operational Unit will, when established, function as a financial clearing house for the EBONE IP service and the IXI X.25 Production Service. The best implementations of both technologies for the best of the the European R&D community. This could truly be called a balanced approach. APPENDIX Calculations of Average Packet Sizes in Internet Networks As we are using NNStat to gather all IP byte and packet counts in NORDUnet it is easy to make a calculation of the average packet sizes. (fi = Finland, dk = Denmark, no = Norway and se = Sweden) europe-fi 55174477 packets, 11626545862 bytes -> avg pkt size 210.72 europe-dk 125112209 packets, 18838107299 bytes -> avg pkt size 150.57 europe-no 127259773 packets, 18835753323 bytes -> avg pkt size 148.01 europe-se 950619 packets, 61044589 bytes -> avg pkt size 64.21 A total average packet size for traffic between Europe and the NORDUnet in May 1992 = 143.38. As Finland has large FTP archives heavily used all over the world their packet size may not be representative for most national IP backbones which probably are closer to Sweden, Denmark or Norway in average packet size. 128 byte packets would perhaps be close to an overall average of packet size in IP networks. An average packet size of 128 octets with an initial efficiency of 16 percent on 2 Mbps gives 328 Kbps. Using off-the-shelf IP router technology it is possible to utilize up to 90 percent of the total available capacity. This means that a network with a 512 Kbps international connection would decrease its usable capacity with around 130 Kbps, from 460 Kbps to 330 Kbps by purchasing a 2 Mbps IP connection from the IXI Production Service. It should be noted that packet size distributions are not usually smooth but bi- to tri-modal. Applications like telnet and xwindows generate small packets while ftp generates bigger packets. All kind of acknowledgements are very small packets. This means that some application will be hit more severely by a low packet forwarding rate. For analysis of average packet sizes in the Internet see papers by Hans Werner Braun and John Crowcroft.