Subject: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Tue, 10 May 2016 07:08:01 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dime-drmp-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I fully agree with all discuss comments made by Ben and Alissa. However,
the summary here might be that this information might simply be not very
useful for the uses cases described. And there might be other mechanisms
that do not require any trust and that can address the uses cases easier
and more appropriate such a simply prioritization of a certain
application in the request handler/request agent or relative priorities
within one application (on sent-out). 

However, the one part that does actually concern me is:
"When using DRMP priority information, Diameter nodes MUST use the
   default priority for transactions that do not have priority specified
   in a DRMP AVP."
This part could lead to starvation of requests that do not define a
priority, e.g. because there are not supporting it (yet). However these
starved requests could effectively have a higher priortiy than the
request that they get starved by.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Why do you need 15 different priority levels? Wouldn't be two enough for
all or your use cases?

---

From: <[email-masked]>
Date: Wed, 11 May 2016 18:23:21 +0000

I still don't get the issue with multiple applications when defining a solution that is actually application-agnostic (with the clarification given in my previous mail)

I think it is clear that some text is required to clarify the need for the default handling and the reason for the "should" with the alternative "operator policies/application guidelines".

But I will see the additional text that will provide in the updated draft.

Thx all the constructive discussion.

Lionel

Not sent from an IPhone.

Le 11 mai 2016 19:11, Alexe Melnikov <[email-masked]> a écrit :

Hi Mirja,

> On 11 May 2016, at 07:07, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
>
> Okay let me go for an example here and see if that can be a use case that we are talking about.

Yes, this is helpful.
>
> You have a system where some clients run a communication service for emergency doctors as well as for firefighters and then there are also ‚normal‘ users that run some kind of communication service.
>
> Now you actually have an emergency: some part of the system is down and the number of request is high such that the system is overloaded.
>
> Both the emergency doctors have would have two different priority classes, one for important message about instruction (what and where people should do something) and one for communication between the doctors/firefighters which has still higher priority than any other communication of the other people (as you assume doctors and firefighters are more responsible to not misuse this communication channel).
>
> Now only the emergency doctors communication service was upgraded to use this extension, but the firefighter’s administrations is just too slow or they currently have not enough money because they have specialized expensive hardware and software that is not easy to change.

"Doctor, it hurts when I do that..." - "Don't do that!"

I don't think this would be a common deployment case.

I agree that there is an issue in the scenario you specified. Default priority helps with a single application + normal (unupgraded) traffic. I do think it helps with the most common case. So instead of having lots of SHOULDs and MAYs, I suggest we add text describing possible issues and when multiple DIAMETER applications are deployed we either recommend that all clients are upgraded to support this extension at the same time or at least deployments specify compatible policies for different applications.

I can suggest some text.

> Is it okay in this situation that the private chat of two doctors about their last ski-holidays starves requests to access the network to send instructor message to the firefighters?

We can't prevent all problems like this, as the above is really a social problem combined with misconfiguration. But we can warn about it.
>
> (And how do i make sure that that all other other requests actually select a lower priority than 10…? But that’s a different question…)
>
> Mirja
>
>
>> Am 11.05.2016 um 06:59 schrieb Alexey Melnikov <[email-masked]>:
>>
>> Hi Mirja,
>>
>> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
>>
>>>>> I don’t think it is a good idea to assign a default priority to non-priority-defined requests at all. If you have high priority traffic that does not support this extension (yet) this traffic could be starved by lower priority traffic when assigning a middle range priority. I don’t think that is what you want to achieve.
>>>> SRD> Actually, this is what we want to achieve.  It is an requirement that messages explicitly marked as high priority get treated even if it results in starving lower priority messages.  The starving of lower priority messages is not an problem, it is a requirement.
>>>
>>> I think we are still talking past each other.
>>
>> Most definitely :-).
>>
>>> If you explicitly assign a priority, starvation might be okay. However, if you don’t have a priority explicitly signaled, the transaction might have a very high priority
>>
>> So some agent in the system needs to decide that a transaction is important.
>>> but you just don’t know and by assigning a random mid-range priority this important request could get starved.
>>
>> Here I disagree with you, because the way to know that a transaction is important is to upgrade client to explicitly assign high priority to it. So default priority is a backward compatibility mechanism, that would work for most common cases. You seem to be suggesting that when this extension is deployed all clients need to be updated at the same time. This is not realistic.
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.