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

[Dave Crocker <[e-mail]>]

On 6/7/2012 2:42 PM, Alexey Melnikov wrote:
>> 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.

"Mentioned" is an accurate choice of vocabulary.

By calling for use cases, I mean sufficient description to make the 
nature, needs and dynamics sufficiently clear that they motivate design 
choices.  This is in contrast with having the document assume that the 
reader knows what the use requires.


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

Probably.

So... For more than 6, I suggest that...


> Also see the new Appendix E in -16.

well that argues from some additional room, but provides no rationale 
for having a space more than 3 times larger.

Since the values are transmitted as text, no that you don't really need 
to specify specific numbers, other than to say it is a decimal number. 
That is, the specific range is a function of the specific profile that 
defines the semantics of the numbers.

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

ack

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net