SOME CONCERNS WITH THE IXI PRODUCTION SERVICE
- Date: Fri, 07 Aug 92 00:34:53 +0200
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.