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

[<[e-mail]>]

Hi,

I think that it is important to remind that "Diameter applications" are specific applications of the Diameter protocol in the AAA network, in the core network/back-end infrastructure managed by an operator network.
In the example below, the key point is to characterize the traffic at the entry of the core network by a AAA client in front of a non-Diameter based network. Examples of such AAA client are Network access servers or IP gateway in mobile networks.

A AAA client supporting the new extension will have a set of criteria to determine the priority value to include in every initiated Diameter message. 
They will be then able to make the distinction between priority requirements for each "service" (e.g. emergency doctors/firefighters/voice services etc.).
The determination mechanism is out of scope of this document but an example could be to rely on another priority indication conveyed in signaling planes used in the front-end network, ex. in SIP or directly at the IP layer.

If the AAA client are not upgraded to support the new extension, there is no way for the AAA client to indicate the priority to apply message per message. It will just send the Diameter messages to other Diameter peers as done today.
The other peers can be a Diameter server or a relay/proxy. And these peers can be upgraded or not. If they are upgraded, they will have to cope with messages with or without priority indication. And in such a case, the recommendation is to handle unmarked Diameter messages as if they were included the value 10 when no other information is available. 

Now, if you can identify that the unmarked messages must be handled with a higher priority even if not marked, you can still do it, using operator defined policies or application-specific handling. This can be done per interface or at the Diameter application level, saying message x from application Y has higher priority than message A from application B. But the last example (handling at the Diameter level) illustrates that the nodes handling the message without priority need to be application-aware, i.e. able to understand the semantic of the received messages, and they have to be either a Diameter proxy or a Diameter server (as defined in the RFC 6733), which exclude Diameter relays that are application-agnostic.

The whole purpose of this solution is to define a mechanism that can work with application-agnostic nodes (including relays) and without the resort to specific operator policies. Ad this includes the need for a recommended default handling of unmarked messages.

I hope that it helps to clarify the discussion.

And I agree with the responses provided by Steve, Janet and Alexey.

Regards,

Lionel

> -----Message d'origine-----
> De : Steve Donovan [mailto:[e-mail]]
> Envoyé : mercredi 11 mai 2016 15:22
> À : Mirja Kuehlewind (IETF); Alexey Melnikov
> Cc : [e-mail]; [e-mail]; [e-mail];
> The IESG; Gunn, Janet P
> Objet : Re: [Dime] Mirja Kühlewind's Discuss on draft-ietf-dime-drmp-05:
> (with DISCUSS and COMMENT)
> 
> Mirja,
> 
> Today, without DRMP, all of the traffic is treated the same by relays as relays
> do not, by design, have application level knowledge.  In many cases, servers
> do not have enough context to determine the priority of a message.  In
> general, the Diameter client is the only one who has that knowledge.
> 
> You are correct that if the firefighters traffic does not get priority marked
> then the firefighters traffic is thrown into the default bucket with all of the
> other non emergency traffic.
> 
> The only way to avoid this is to upgrade the firefighters system. There is no
> way, without a client marking a requests priority, for an agent to understand
> the priority of a message.  Agents don't have application level knowledge.
> Your proposal of having Diameter nodes understand the intrinsic priority of a
> message without an implicit priority marking is not possible in Diameter.  This
> is why the working group decided on the DRMP mechanism.
> 
> Steve
> 
> On 5/11/16 6:07 AM, Mirja Kuehlewind (IETF) wrote:
> > Okay let me go for an example here and see if that can be a use case that
> we are talking about.
> >
> > 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.
> >
> > 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?
> >
> > (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
> <[e-mail]>:
> >>
> >> Hi Mirja,
> >>
> >> On 10 May 2016, at 17:59, Mirja Kuehlewind (IETF)
> <[e-mail]> 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.