Re: Yet another X.400 vs SMTP question

Julian Onions <j.onions@nexor.co.uk> Tue, 01 June 1993 12:47 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03027; 1 Jun 93 8:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03023; 1 Jun 93 8:47 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa07293; 1 Jun 93 8:47 EDT
X400-Received: by mta haig.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; Relayed; Tue, 1 Jun 1993 11:49:20 +0100
Date: Tue, 01 Jun 1993 11:49:20 +0100
X400-Originator: osi-ds-request@cs.ucl.ac.uk
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=uk.ac/ADMD=gold 400/C=gb/; haig.cs.uc.105:01.05.93.10.49.20]
Priority: Non-Urgent
DL-Expansion-History: osi-ds@cs.ucl.ac.uk ; Tue, 1 Jun 1993 11:49:19 +0100;
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Julian Onions <j.onions@nexor.co.uk>
Message-ID: <8307.738931690@nexor.co.uk>
To: " (Erik Skovgaard)" <eskovgaa@cue.bc.ca>
Cc: osi-ds@cs.ucl.ac.uk
In-Reply-To: <9305280040.AA00691@cue.bc.ca>
Subject: Re: Yet another X.400 vs SMTP question
Discarded-X400-IPMS-Extensions: ccitt (0) data (9) pss (2342) (2342) (19200300) (200) (1)

> Thanks for the info on the new "commercial" version of PP.  It is good
> to hear that you are making progress.  In all fairness, it probably
> should have a new name so it is not confused with the free version. 

As the writer of a large part of the PD PP, I feel rather aggrieved by
your sweeping comments about PP being unfit as a general X.400
implementation. If you would like to level specific criticisms I will
attempt to respond in a fair and responsible manner. If so, it is
probably better done on another list (pp-people@cs.ucl.ac.uk or the
iso list).

> Although the effort is appreciated, I must tell you that PP is not up to
> par with commercial implementations. 

This rather upsets me, I think this is wholly unjustified (talking
just about the PD version for now). PP had the 1988 protocol support
at least a year ahead of any commercial version I was aware of. PP is
even now shifting many thousands of X.400 messages a day in many
sites. I suspect (but have no proof) that PP is probably delivering a
significant fraction of the worlds X.400 traffic now. It has been used
as a basis for many commercial products too.
PP was one of the first implementations to support RFC987, RFC1148
and RFC1327.  PP also has many added features to cope with broken
commercial implementations, I could list a number of these but the
point is PP does over and above what is required in the pursuit of
interoperability. 

Sure PP has its problems, but I would argue they are not much more
than any other commerical implementation, and as far as X.400 goes I
think we are better than most. We implemented the whole standard, not
a subset or a profile, for instance:

- It can deal with a queue of 15,000 messages and maintain optimal
  ordering of message delivery (many systems just can't deal with that
  sort of volume - due to the linear scanning of queues). Again I
  haven't seen   many commercial systems, but that would be a good
  stress test.
- It can handle the requirement of a message with 32767 recipients,
  although it takes a while to check all those addresses and requires
  a lot of memory.
- It can handle 128 nested forwarded messages.
- It can handle essentially an infinite number of body parts (tested
  up to 1000)
- We've certainly shipped messages in excess of 2Mb in size.

> The code is bulky, slow and has
> not passed conformance testing.

Bulky, yes - I have to agree with that - but you can level that at
commercial implementations. You can also point out the huge
functionality that PP has (gateways, plug in reformatters, flexible
routing, management console ...). It could be reduced in size I'm
sure, but not by an an enormous amount without loosing much of its
functionality.

Slow - what is slow.  PP (the public version) has to my knowledge
deliver 30,000 messages in a day, over at least a weeks period. Much
of this isn't X.400 traffic. Now this is around about 1 message every
3 seconds, day and night sustained to systems all around the world. Of
course it can be faster if all messages are being either delivered or
routed to a local system. I haven't seen statistics for other systems,
but I would be suprised if they are processing orders of magnitude
more messages than this. If so, on what hardware (the above figures
are for a sun 4/330).  Can you give statistics for other commercial
systems? I would be quite interested in their throughput in
comparison. (I do remember comparing it against sendmail, and although
I can't remember the final results I think it was not too far out,
especially with big queues).


Conformance test - for a public domain system! As I am sure you are
aware conformance tests cost real money, $50000 I have heard of. You
also need to retest your system everytime you change the software.
When PP was put through a conformance test there was relatively little
wrong with it (lots of little detail but nothing major). There were
some interesting things thrown up, but nothing really of a show
stopper nature. Some of the commerical systems we talk to on a daily
basis would not pass conformance I am sure, as we have to work around
their problems.


Its easy to take pot shots at public code. If there were another free
competitor, it would be a fairer comparison.

Julian.