On Sat, 19 Aug 2000 [EMAIL PROTECTED] wrote:
> Well spotted Richard.
>
> I haven't looked at this particular paper, but one of the benefits of all
> the ATM development work that the Telcos have done over the last 5 or so
> years is the intense focus on scheduling algorithms with an emphasis
> on fairness and optimal resource usage (oh, and charging for every
> packet at every QOS level). Admittedly it tends to be for very short
> lived queues (such as cell queues in an ATM switch), but if you're into
> reasonably heavy mathematics then this area is rich in related reading
> material. Personally I only recommend it for insomniacs...
an interesting point, below are my comments on where the differences
betwen the models might lead to problems in appying the theories acorss
the technologies
(In a previous job I built large campus networks based upon X.25,
ethernet, fddi and ATM; as well as mail systems based upon greybook mail,
X.400, cc:mail and SMTP)
Queue numbers
-------------
In an ATM network devices only have a finite number of known destination
(next hop) devices whose ststus they have to be concerened about when
determing the queue behavior.r
Open email routers (like postfix and qmail) (based on SMTP and the DNS)
have a practically infinite targets (destination addresses) and the number
of them is unknown. However in comparison to the others below they have
the higest performance as they avoid modifying the contents of the
message. The number of queues will be most unlike that of an ATM device.
If one considers a closed mail system with similar characteristics to the
TAM model such as cc:Mail where the post-offices are connected by cc:Mail
routers with a known number of other post-offices as targets (routing to
the Internet is handled like another post-office with a gateway from the
closed to the open system) then each router might be considered to behave
like an ATM switch, however in this system the routers can only implement
round-robin serving of the queues based upon alphabetical sorting of the
target post-office names and so the QoS is frankly appalling. (if you have a
workgroup where people most often communicate within a post-office this
is okay, but for cross-postoffice workgroups it just doesn't work)
Multi-protocol mail routers like PP provides are rich in gateway
functionality, but the performance of these systems is really horrible as
they have to cope with all of the transformations necessary to move data
between protocols. In PP's case the generic configuration converted
generally (as one might expect) but judiciously tweaking the configuration
it was possible to stop it reformatting headers and body parts where not
necessary. there were internal queues where a message was queued for
reforatting, first of the header and then the body, for delivery, and
finally for deletion. The overhead of the ISO ROSE layer for IPC really
did kill its performance, and the number of sycronous directory writes did
not help either
Discard of messages
-------------------
For data applications (ie not voice ot video) the AAL's expect there to be
some overlying network prorocol such as IP or ethernet which will retry
the sending of data if they run out of queueing resources. (if the ATM
device decides to discard a cell within a higher layer data frame then it
can determine which are the following cells, and so discard the rest of
the frame alleviating congestion without affecting more frames than ar
necessary.
In the case of mail messages we rarely see large binary attachments split
across multiple mail messages which have to be manually reassembled. It is
generally considered VERY BAD for a mail system to loose or purposefully
discard a message to alleviate congestion.
Blocking architecture
---------------------
Finally, almost all ATM switches operate with non-blocking routing
architectures. conversely mail systems work by receiving a message into a
queue, and then effectively blocking until the message is pulled up out of
the queue (think q-smtp -> q-queue <block> -> q-send -> q-rspawn ->
q-remote) rather than doing something like
q-smtp -------------> q-remote
\ \ failure
-> q-queue q-send -> q-rspawn
so if the destination MTA is available the message is forwarded
immediately (and written into the queue) so the routing of messages
through a gateway to internal systems is very fast, but if the remote MTA
is down (or goes down) then the message is written into the queue for
qmail-send to retry later. I think this is where some hard performwance
gains will be made in the next generation of mail routing systems after
qmail and postfix.
to prove the block exists where I say it does, remove the trigger file
from the qmail queue directory and see the performance of the system
plummet as the trigger mechanism for the queue notifying qmail-send there
is work to do in the queue fails.
RjL
==================================================================
You know that. I know that. But when || Austin, Texas
you talk to a monkey you have to || Email: [EMAIL PROTECTED]
grunt and wave your arms -ck ||
