[Spambayes] Two Stage Plan

Gary Robinson grobinson at transpose.com
Thu Dec 19 15:08:26 EST 2002



> 
> You've never had any exposure to datacenter cost accounting, have you?


I've had two period in my life in personally funding, designing, and running
online consumer systems, and the current one has a paid up Oracle license.

Your argument seems to depend on the assumption that you have knowledge of
such things and I don't.

'Nuf said for now.

More when I have time.

Gary


> You're
> willing to turn over the control of e-mail to Microshaft, so you're probably
> not
> expecting to pay Oracle license fees for the database, but SQLServer licenses
> for
> systems with huge arrays of processors come with heart-stopping price tags as
> well.
> Then you pay for the computers, the maintenance agreements, the DBAs to keep
> it
> running. And for this scale of software, the database license is not a
> one-time
> expense, it's annual.
> 
> Also note that at the speed this will have to operate you can't use "secure
> online
> storage." You have to use silicon storage, multi-gigabyte arrays of virtual
> disk in
> front of the RAID arrays. I seriously doubt that anyone knows how to build the
> system you propose yet, although the InifiniBand proponents may be thinking in
> the
> right ballpark. (Not delivering, mind you, but at least thinking about it.)
> And
> behind the memory-resident part of the system you still are going to need the
> fastest RAID arrays. (I also don't think that you can store 5 or 8 or 50 bytes
> of
> data in a database with an incremental 5, 8, or 50 bytes of storage used.)
> 
> Given the latency requirements and the volume, I would expect the backup
> system to
> be an interesting exercise. Surely you aren't planning on a single global
> system to
> authorize all e-mails without backup, are you?
> 
> Even if your cost estimates weren't several orders of magnitude too low, the
> very
> concept of turning e-mail over to any single system (particularly the
> generally-malevolent convicted monopolist in Redmond) is a fundamental evil.
> Monocultures are destructive to the environment, and this happens to be an
> environment I care about.
> 
> Van
> 
> Gary Robinson wrote:
> 
>>>> this application.
>>> 
>>> You can only shrink it that small if you give up tracability.
>>> Otherwise you need things like the datetime, sender/receiver,
>>> and unique identifiers... minimum of about a hundred bytes
>>> once indexes are added, etc.  More if you use non-binary
>>> formats or wrap stuff in XML or something stupid (but popular!).
>> 
>> True, but I still don't see it as an issue. The email addresses would be on
>> file at the vendor and could be represented in each transaction as 5 byte
>> (max) binary numbers. 8 if you don't want to be fancy to save space. I can't
>> see this going to more than 50 bytes...
>> 
>> If it did get to be an issue, which again I do NOT think it is due to the
>> cost of storage today and even further decreased cost of storage tomorrow,
>> then tracability COULD be given up, perhaps -- worth considering. We're
>> talking about $.01 transactions here. If worse came to worse and something
>> went askew with one, it simply would not be worth fixing. This is something
>> that needs to be thought about more IF the storage this was an issue, which
>> again, i don't think it is.
>> 
>> Let's forget about the fact that individuals can by 100gig hard drives for
>> $100 or something these days. Suppose we are talking about secure online
>> storage. From Apple, you can get a secure, backed up 1gig online drive for <
>> $400 per year. That would handle, easily, 10 million of these transactions
>> (100 bytes per transaction). That's $0.00004 per transaction for storage.
>> 
>> Physical storage for this is negligable.
>> 
>> The actual CPU time of the updates would possibly be a bigger factor, but
>> really don't think it would be much more. If you disagree we could look into
>> it further.
>> 
>>> 
>>> If you only bill once a year, then you start running into
>>> problems tracking down mid-level fraud (because the customers
>>> won't alert you to problems until they see the bill, and by
>>> then the trail has most likely gone cold).
>>> 
>>> Small-scale fraud is just a cost of business, and large-scale
>>> fraud you'll notice yourself.
>> 
>> Fraud is a factor with most financial transactions, but microsoft would be
>> guaranteeing this service (the delivery of an email) and there would not be
>> fraud in that question as far as I can see. (I.e. ms would not defraud users
>> about whether an email was delivered.)
>> 
>> Again this becomes more complicated if it this is done via cooperating email
>> client vendors, but I don't think that changes the dynamic in a major way.
>> 
>>> 
>>>> 5. Authentication. Again only done in the loading of the account, and
>>>> depending on whether it's part of a larger software rental package, may be
>>>> being done anyway.
>>> 
>>> If you only do authentication at account load time, then you
>>> run into problems with spammers masquerading as other users.
>>> Return-address forgery is already a problem... it'll get
>>> worse as real money gets attached to it.
>> 
>> Encrypted Passwords, etc. Clearly there would be challenges in making
>> everything secure. MS will have already done that as part of its
>> subscription services but some kind of consortium would have to do it from
>> scratch.
>> 
>> It would be interesting to try to quantify that in some way. Any ideas?
>> 
>>> 
>>>> 6. Retrieval costs -- outside audits. I think this probably goes away too
>>>> for the reasons above but you'd have to spell it out more for me to be
>>>> sure.
>>> 
>>> No, outside audits don't go away.  Anyone who handles large
>>> amounts of money (and this would be a large amount of money,
>>> even at only a penny per email) gets their accounting practices
>>> scrutinized.  I'll grant that MS is already under such scrutiny,
>>> but being a broker as well as a vendor adds a whole other dimension
>>> to the mess.
>> 
>> OK, right, the central organization, whether MS or a consortium, would have
>> to handle audits.
>> 
>> For MS, auditing this would probably be folded into overall audits in such a
>> way that it wouldn't be a major factor. it could be more of one for an
>> independent consortium. How do we quantify this?
>> 
>> Gary
>> 
>>> 
>>> - Alex
>>> 
>> 
>> _______________________________________________
>> Spambayes mailing list
>> Spambayes@python.org
>> http://mail.python.org/mailman/listinfo/spambayes
> 
> --
> ----------------------------------------------------------
> Sign up now for Quotes of the Day, a handful of quotations
> on a theme delivered every morning.
> Enlightenment! Daily, for free!
> mailto:twisted@whidbey.com?subject=Subscribe_QOTD
> 
> For web hosting and maintenance,
> visit Van's home page: http://www.domainvanhorn.com/van/
> ----------------------------------------------------------
> 
> 




More information about the Spambayes mailing list