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

[Alexey Melnikov <[e-mail]>]

Hi Dave,

On 5 Jun 2012, at 12:45, Dave Crocker <[e-mail]> wrote:

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

I believe both of these are mentioned in the 1st paragraph of the Introduction.
If you think something is missing, please suggest some text.
> 

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

I am working to address this (-16 doesn't quite do that).

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

Hmm, Appendix A?

Also see the new Appendix E in -16.

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


Well, there are Appendices A, B and C. But as I said above, I will work on more text.