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

Dave Crocker <dhc@dcrocker.net> Tue, 05 June 2012 11:45 UTC

Return-Path: <dhc@dcrocker.net>
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 4917421F867A; Tue, 5 Jun 2012 04:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 RWNcSOtuIvKB; Tue, 5 Jun 2012 04:45:34 -0700 (PDT)
Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by ietfa.amsl.com (Postfix) with ESMTP id 525D021F862A; Tue, 5 Jun 2012 04:45:34 -0700 (PDT)
Received: from [10.102.2.236] ([212.184.65.20]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id q55BjQm9029430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 04:45:31 -0700
Message-ID: <4FCDF13F.3000106@dcrocker.net>
Date: Tue, 05 Jun 2012 13:45:03 +0200
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ned Freed <ned.freed@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>
In-Reply-To: <01OGAJ8GBR2Q0006TF@mauve.mrochek.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh11.songbird.com [72.52.113.11]); Tue, 05 Jun 2012 04:45:34 -0700 (PDT)
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
Reply-To: dcrocker@bbiw.net
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: Tue, 05 Jun 2012 11:45:35 -0000

My hope is that I can respond to Ned without contradicting him.  I'm
prefacing with that statement because this is proving a challenging
topic having -- as he notes -- some unexpected characteristics...


On 6/4/2012 11:47 PM, Ned Freed wrote:
> 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.

Priority is a mechanism intended to deal with situations of limited
resources.  In other guises, that's an aspect of queuing.  An
observation made by Kleinrock and others about such queuing is that it
only works well in periods of transient congestion.  In protracted
periods the only thing that suffices is more capacity and in periods of
no queuing, there's no need for the mechanism.

Perceiving no difference equates to "we don't need the mechanism".

The modification for some prioritization -- the role-based usage that's
been cited -- is protracted declining of service to lower rank
originators. That's no longer 'queuing' in an operational sense, it's a
termination of service for some.  Besides the military example, that's
what happens for telephone emergency mode, as I understand it.

So as soon as we say that user's perceive no difference, we are saying
that this mechanism isn't needed.

Therefore we need to define use cases that /do/ need to show a
difference.  I believe the military case and the emergency service case
have plenty of experience in that regard, establishing the value of
traffic segmentation.


> 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.

I think the basic syntax of prioritization is simple:  differential
labeling of the object with a rank-ordering value.  Handling of labeled
objects will, at a minimum, simply mean taking higher-labeled stuff
before lower-labeled stuff.

In more sophisticated queue-management situations, handling could be
more complex.  (I've just heard of recent work by van Jacobsen, for IP
routers, that provides an example, but the details don't matter here.)


> There's a reason why every specification I've seen that mentions
> email prioritization, going back as far as FIPS PUB 98 (RFC 841) and
> including X.400, GOSIP, various LAN email systems, either omits
> entirely any description of what priorization actually means or
> contains nothing but a bunch of handwaving.

That's why I'm suggesting partitioning mechanism syntax from assignment
semantics.  Environments that insist on using the mechanism have the
obligation to deal with this hard stuff.   But we don't have to, both
because we can't do it now and because it needs to be different for
different environments.

However, as usual, this sort of partitioning only works when one or two
real-world cases are applied.  IMO, this means that this spec needs to
be accompanied by two specifications for the policy-side that provides
details for using the mechanism in different environments.  Hmmm.
Military.  Emergency Services.  That's two.


>> The environment will be left with individual clients taking more
>> than their fair share. Or trying to.
>
>> Absent very specific rules to be applied consistently across the
>> trust environment, what is most likely is that every client will
>> always claim top priority and no one will actually get it. (This
>> is a well-known phenomenon for this sort of game-theoretic
>> condition.)
>
> I have no good explanation for it, but the evidence I've seen says
> otherwise: Quite a few existing systems support message
> prioritization, but I've yet to encounter a case where everybody
> claims the top priority.

But what you've described are situations where prioritization didn't
matter.  So user's had no incentive to use it.

Although I can't cite papers, I recall hearing of extensive research
(and experience in non-Internet contexts) that demonstrate the "everyone
sets to max" phenomenon.


On 6/5/2012 1:35 AM, Pete Resnick wrote:
>  I find more than 5 "priorities" complete
> overkill,

That's my assumption, to.  One can easily argue for 3.

In any event, for more than 5, I suggest that there needs to be explicit 
justification that is based on documented real-world models.  (I don't 
care whether they are Internet-based.  If there are useful models 
elsewhere, we can assume they might show up on the Internet.)


>    and I think the likelihood that in a modern SMTP system any
> of these priorities will cause a significant change in delivery time
> (or order, for that matter) to be exceedingly low.

1. Most systems experience little-to-no queuing.

2. Until an environment has a meaningful pattern of queuing, no this 
mechanism isn't need.

3. Some environments are known to experience queuing.  That's why the 
combination of military and emergency should suffice as justification, 
IMO.  However they don't seem to be getting referenced to provide their 
substance.


d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net