Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14

John C Klensin <john@jck.com> Mon, 04 June 2012 23:14 UTC

Return-Path: <john@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B05321F85A8; Mon, 4 Jun 2012 16:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5-tS+AStbVy; Mon, 4 Jun 2012 16:14:47 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEE511E80EC; Mon, 4 Jun 2012 16:14:47 -0700 (PDT)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john@jck.com>) id 1SbgNy-0001QX-6g; Mon, 04 Jun 2012 19:08:30 -0400
Date: Mon, 04 Jun 2012 19:14:34 -0400
From: John C Klensin <john@jck.com>
To: Ned Freed <ned.freed@mrochek.com>, Dave Crocker <dhc@dcrocker.net>
Message-ID: <F6882C013F7272CED4D345A9@PST.JCK.COM>
In-Reply-To: <01OGAJ8GBR2Q0006TF@mauve.mrochek.com>
References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jun 2012 23:14:48 -0000

--On Monday, June 04, 2012 14:47 -0700 Ned Freed
<ned.freed@mrochek.com> wrote:

>...
> More precisely, it may "work" in some sense, but it may not
> deliver the results
> you expect, which given what I understand the intended uses to
> be may be problematic.

I mostly agree, but see below.

> OTOH, it may actually work very well, if for no other reason
> than most modern
> mail systems are able to deliver messages in a matter of
> seconds most of the
> time, which will make it difficult for a human user to observe
> any tangible
> difference for different priorities.
> 
> And in practice since prioritization is very complex - to the
> point where, as
> I've pointed out previously, the most obvious strategies may
> actually result in
> increased latency, especially under high load conditions - so
> aligning behavior
> across multiple implementations may prove to be a practical
> impossibility.

Yes in principle.  In practice, I've seen one set of communities
that have repeatedly expressed high levels of demand for
prioritization.  Those communities are military or ones with
aspirations to behave like military ones.  For those
communities, "messages from the General get more delivery
priority than those from the Lieutenant" have obvious meaning
and obvious intent.  Moreover, the obvious response, especially
if someone is a communications officer in that chain of command,
is to salute and say, "yessir, we will transmit the General's
message with instructions to process it at higher priority".
If what happens after that is that this information is passed
along but no MTA does a thing about it, your observation about a
second or two takes over, there is a report back to the General
of complete conformance to his wishes and recognition of his
exalted status, and everyone is happy.   And, if that trick
doesn't work, it is always possible to artificially delay  the
Lieutenant's mail for a while, even if the General has no mail
in the queue, just to help prove that the General is important.
Simply dumping the Lieutenant's mail into the queue when it
arrives while trying to immediately process the General's mail
for delivery or forwarding would probably be a sufficient
implementation.   I don't have enough data to claim that
scenario occurs many times around the world every day, but it
has got to be close.

That view leads to an unattractive variation on Ned's question...

> All that said, I am completly at a loss as to what, if
> anything, to do about
> all of this. To nail down what prioritization means in an
> operational sense
> requires a far more detailed model of how MSA/MTA/MDAs work
> than we currently
> have. And I given what I know about the internals of various
> MTAs, I despair
> of finding any sort of model that is simultaneously
> sufficiently general
> and sufficiently accurate that we could even talk about this
> stuff sensibly.
>...

I agree about the model issues (and have said so).  But suppose
the above scenario, for which the model is good enough within a
chain of command and irrelevant outside it, _is_ the use case.
The question is then whether it is appropriate for the IETF to
support this type of essentially "do little but get folks to
feel good" option.  I'd normally say "no".  But, if the reality
is that people will demand mail prioritization --I suggest that
they will as long as there are Generals and they outrank
Lieutenants and maybe as long as there are mail service
providers who can figure out how to charge one class of
customers more for exactly the same service because that groups
is willing to pay to be important-- and, that by standardizing
something we can at least do a security analysis and contain
interoperability issues, then maybe we should just hold our
noses (or Alexey's) and do it.

   john