<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

SOME CONCERNS WITH THE IXI PRODUCTION SERVICE

  • To:
  • From: Bernhard Stockman < >
  • 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.




  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>