Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

[<[e-mail]>]

When determining if a request should be throttled, there are three cases:

- Only a Realm report (based on the definition from the meeting) matches the message -- In this case the Realm report MUST be used to determine if the message is throttled.
- Only a Host report matches the message -- In this case the Host report MUST be used to determine if the message is throttled.
- Both a Realm and Host report match the message -- In this case the Host report MUST be used to determine if the message is throttled and throttling based on the Realm report MUST NOT also be applied to the message.

I'm ok at the moment with this wording, but I don't think we've thought through the implications of prioritizing Host reports over Realm reports when both apply.  As such, this is open to change in a future version of the draft.

[LM] OK

>

      > About renaming "Realm" as "Realm-Routed-Request", no strong
      issue as

      > soon as the principle above are kept.

SRD> If we go with your proposal above then there is no name change but rather a change in the definition of Realm report.

[LM] don't think that the current definition needs to be changed. However the behavior of the reacting node should be clarified when both Host and Realm report type are applicable to a single message.

If we go with Ulrich's proposal then we should change the name from Realm to RRR (or some other name yet to be suggested).

If we go with three reports then we also need to change the name of the existing Realm report to RRR and redefine Realm to match the above logic.

[LM] let's play with only two for now.

>

      > The need for realm-based type that would apply to any request
      (even

      > if a "Host" exists for a destination-host in the request) was


      > challenged and not retained. Ben was supposed to lock you in
      a room

      > and to convince you that this last report type was not
      needed.

This is NOT my recollection of the decision and is NOT what is reflected in the minutes.  This is also NOT what you say above.

Here's the relevant portion of the minutes:

Report types - there was consensus that Host and Realm report types needed to be retained. Ben suggested that if a node sent a Realm report, it needed to be an absolute authority for the realm. Dave did not agree that agents needed to be authoritative and felt that clients should be able to make their own decisions on conflicting realm reports, which Lionel disagreed with. Maria Cruz agreed with both proposals because it would be deployment dependent. Steve said that the draft should provide guidance that a sender of the realm report should be an authority and that realm reports should not contradict. It should provide guidance on what the client should do if does receive different realm reports. Ben pointed out that, in the case where a realm was sending overload reports, individual servers could send Reductions of 0% in their reports to provide more information to clients.


ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a proposal on whether to remove or to incorporate.

ACTION: Next version of DOIC will keep Host and Realm and leave Realm-Routed-Request an open issue.

ACTION: Clarify precedence of the host and realm report types and what actions to take when they are received.

[LM] ok



>

      > Lionel

      >

      > Envoyé depuis mon Sony Xperia SP d'Orange

      >

      > Steve Donovan <[e-mail]><mailto:[e-mail]> a écrit :

      >

      > Consensus is obviously a fleeting and temporary thing.

      >

      > Let us make sure that we are precise in our definitions of
      the

      > report types we are discussing.

      >

      > Host report - Applies when the destination-host AVP is
      present in

      > the request. Realm-Routed-Request (RRR) - Applies when there
      is no

      > destination-host AVP in the request. Realm - Applies to 100%
      of

      > requests sent to the realm.

      >

      > These are the definitions used in our discussions in London
      and in

      > various places in our email discussions.

      >

      > Can we please agree to use these definitions going forward so
      we are

      > all talking about the same thing.

      >

      > Regards,

      >

      > Steve

      >

      > On 3/25/14 10:27 AM, [e-mail]<mailto:[e-mail]> wrote:

      >>

      >> Hi Maria Cruz, All,

      >>

      >>

      >>

      >> In the previous mail, you wrote:

      >>

      >>

      >>

      >> /That is, we have two reports, host and realm. /

      >>

      >> /Host applies when Destination_host is present, and then
      it takes

      >> precedence over Realm. If both are present, only Host is
      applied./

      >>

      >> /Realm applies when only Destination_realm is present./

      >>

      >>

      >>

      >> And I agree with this statement. But I'm not sure that
      this is the

      >> case discussed by Ulrich.

      >>

      >>

      >>

      >> Whatever the name of the realm report type, is there an
      agreement

      >> on the description given above by Maria Cruz and
      discussed in

      >> London?

      >>

      >>

      >>

      >> Regards,

      >>

      >>

      >>

      >> Lionel

      >>

      >>

      >>

      >> *De :*DiME [mailto:[e-mail]] *De la part de*
      Maria

      >> Cruz Bartolome *Envoyé :* mardi 25 mars 2014 16:21 *À :*
      Wiehe,

      >> Ulrich (NSN - DE/Munich); ext Steve Donovan;
      [e-mail]<mailto:[e-mail]> *Objet

      >> :* Re: [Dime] Resolution on action to discuss the need
      for

      >> Realm-Routed-Reports

      >>

      >>

      >>

      >> Dear all,

      >>

      >>

      >>

      >> I support option 1 a well

      >>

      >> Cheers

      >>

      >> /MCruz

      >>

      >>

      >>

      >> *From:*DiME [mailto:[e-mail]] *On Behalf Of
      *Wiehe,

      >> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de
      2014 16:15

      >>  *To:* ext Steve Donovan; [e-mail]<mailto:[e-mail]> *Subject:* Re:
      [Dime]

      >> Resolution on action to discuss the need for
      Realm-Routed-Reports

      >>

      >>

      >>

      >> Steve,

      >>

      >> Thank you for this summary.

      >>

      >> Please see inline.

      >>

      >>

      >>

      >> Ulrich

      >>

      >>

      >>

      >> *From:*ext Steve Donovan
      [mailto:[e-mail]] *Sent:*

      >> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN
      -

      >> DE/Munich); [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>
      *Subject:* Re:

      >> [Dime] Resolution on action to discuss the need for

      >> Realm-Routed-Reports

      >>

      >>

      >>

      >> Ulrich,

      >>

      >> I mean going backwards from where I thought we were after
      the

      >> London meeting.

      >>

      >> We are clearly out of sync but hopefully we can fix that.

      >>

      >> Here's my understanding of the status of #23 and #55.

      >>

      >> Prior to London meeting:

      >>

      >> #23 status: - Agreement to change the name of existing
      realm

      >> reports to realm-routed-reports (RRR).

      >>

      >> <Ulrich>this includes agreement to keep the (newly
      called)

      >> realm-routed-reports</Ulrich> - Discussions were
      ongoing as to the

      >> need for both realm reports and RRR reports.

      >>

      >> <Ulrich>I would say "...as to the need for realm
      reports in addition

      >> to realm-routed-reports" </Ulrich>

      >>

      >>

      >>

      >> #55 status: - Agreement on adding Realm reports based on
      the

      >> definition that realm reports apply to all traffic sent
      to the

      >> realm.

      >>

      >> <Ulrich>This is what I'm missing. The issue has
      been very briefly

      >> discussed under #34 without conclusion. There was no
      discussion

      >> under #55</Ulrich>

      >>

      >>

      >> - Limited discussion on the interaction between the new
      realm

      >> reports and the existing host and RRR reports.

      >>

      >> After London meeting:

      >>

      >> #23 status: - Tentative agreement in London meeting to
      remove RRR

      >> reports.

      >>

      >> <Ulrich>What was the technical
      argument?</Ulrich>

      >>

      >>

      >> - Ben expressed the strongest concern with this plan.
      Steve and

      >> Ben took action to discuss and come back with a
      recommendation.

      >>

      >> #55 status: - No change

      >>

      >> Summary: - Tentative consensus reached to move forward
      with two

      >> report types - host and realm, with realm having the new


      >> definition. <Ulrich>What was the technical
      argument?</Ulrich>

      >>

      >>

      >> Current status:

      >>

      >> #23 status: - Change the name to RRR - Whether or not to
      remove

      >> RRR and revisit later or keep RRR and revisit later is an
      open

      >> issue.

      >>

      >> #55 status: - My opinion is that we have at least rough
      consensus

      >> on the need to support realm reports.  Others might have
      a

      >> different opinion.

      >>

      >> <Ulrich> There was no comment posted to issue #55,
      also no

      >> proposed solution, so I cannot see where the consensus
      came

      >> from</Ulrich>

      >>

      >>

      >>

      >> Summary: - I believe we have three options:

      >>

      >> 1) Support host and RRR reports 2) Support host and Realm
      reports

      >> -- This was the tentative plan coming out of the London
      meeting

      >>

      >> < Ulrich> There is not even an issue number
      identifying problems

      >> with RRR and proposing to remove RRR</Ulrich>

      >>

      >>

      >> 3) Support host, RRR and Realm reports

      >>

      >> <Ulrich> I support option 1</Ulrich>

      >>

      >>

      >> Regards,

      >>

      >> Steve

      >>

      >> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >>

      >> Steve,

      >>

      >> I don't think we are going backwards (we may be out of
      synch

      >> though)

      >>

      >>

      >>

      >> Can you please summarize the status of #23 and #55.

      >>

      >>

      >>

      >> Ulrich

      >>

      >>

      >>

      >>

      >>

      >> *From:*ext Steve Donovan
      [mailto:[e-mail]] *Sent:*

      >> Monday, March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -


      >> DE/Munich); [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>
      *Subject:* Re:

      >> [Dime] Resolution on action to discuss the need for

      >> Realm-Routed-Reports

      >>

      >>

      >>

      >> Ok, we are going backwards on this one.

      >>

      >> I did not include option three because we had moved past
      that

      >> option in our discussions, both on the list (I thought),
      and in

      >> the meeting.

      >>

      >> I believe that we had come to rough consensus on the need
      for a

      >> realm report and the only remaining issue was whether we
      also

      >> included the RRR report type.

      >>

      >> At this point, the only option is to leave all of the
      issues

      >> related to the report types open and attempt to resolve
      them in

      >> the -03 draft.

      >>

      >> Steve

      >>

      >> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >>

      >> Steve,

      >>

      >>

      >>

      >> I do not agree.

      >>

      >>

      >>

      >> We should still have the option

      >>

      >> 3) support report type 0 (this is called host report) and
      support

      >> of report type 1 (this has been called relam report but
      people

      >> argued it should better be called realm routed request
      report).

      >>

      >>

      >>

      >> Whether or not we need in addition to type 0 and type 1
      (or as a

      >> replacement of type 1) a

      >> realm-no-matter-whether-destination-host-is
      present-or-not report

      >> is an open issue (see #55).

      >>

      >> There are a lot of open questions  with regard to #55 and
      I have

      >> not seen a conclusion.

      >>

      >> Where I have seen a conclusion is issue #34 and that is
      inline

      >> with option 3).

      >>

      >>

      >>

      >> Unless we conclude on #55, or decide to re-open #34,
      option 3) is

      >> what should go in the -02 draft.

      >>

      >>

      >>

      >>

      >>

      >> Ulrich

      >>

      >>

      >>

      >> *From:*DiME [mailto:[e-mail]] *On Behalf Of
      *ext

      >> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM
      *To:*

      >> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]> *Subject:* Re:
      [Dime]

      >> Resolution on action to discuss the need for
      Realm-Routed-Reports

      >>

      >>

      >>

      >> Ulrich, All,

      >>

      >> We have two options for the -02 draft.

     >>

      >> 1) Support Host and Realm as proposed below, removing RRR
      reports.

      >>  2) Support Host, Realm and RRR reports.

      >>

      >> The default plan is to go with option 1 in the -02 draft,
      as that

      >> was the proposal that came out of the meeting in London.
      RRR

      >> reports can be added back in if and when we are convinced
      of the

      >> need.

      >>

      >> If there are strong objections to this then I will update
      the -02

      >> draft to reflect all three report types.

      >>

      >> I plan to make these updates Wednesday morning, Dallas,
      Texas

      >> time.

      >>

      >> Either way I do not expect we will have agreed to wording
      on the

      >> interaction between the report types when a reacting node
      has

      >> multiple report types, all of which apply to individual
      requests.

      >> This will need to be addressed in the -03 draft.

      >>

      >> Regards,

      >>

      >> Steve

      >>

      >> On 3/21/14 4:05 PM, Steve Donovan wrote:

      >>

      >> Ulrich,

      >>

      >> The discussion should be captured in the minutes to the
      meeting.

      >> I wasn't able to find them posted yet.

      >>

      >> Jouni, Lionel, what is the status of the minutes for the
      meeting?

      >>

      >> My reading of emails prior to the London meeting is
      different from

      >> yours.  I believe we had come to the conclusion that we
      needed

      >> host and realm (with the definition of realm as outlined
      below).

      >> We were still discussing the need for
      Realm-Routed-Request

      >> reports.

      >>

      >> Regards,

      >>

      >> Steve

      >>

      >> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >>

      >> Steve,

      >>

      >>

      >>

      >> I don't know what happend in London.

      >>

      >> Can you please summarize the technical reasons that led
      to the

      >> London agreement.

      >>

      >> E-mail discussions prior to London have clearly directed
      towards a

      >> report type that requests throttling of realm routed
      request

      >> messages (i.e. not containing a destination host) rather
      than a

      >> report type that requests throttling of messages routed
      towards a

      >> realm (no matter whether they contain a destination host
      or not).

      >>

      >>

      >>

      >>

      >> Ulrich

      >>

      >>

      >>

      >> *From:*DiME [mailto:[e-mail]] *On Behalf Of
      *ext

      >> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM
      *To:*

      >> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]> *Subject:*
      [Dime] Resolution

      >> on action to discuss the need for Realm-Routed-Reports

      >>

      >>

      >>

      >> All,

      >>

      >> Ben and I took the action item to discuss the need for
      the

      >> Realm-Routed-Reports (RRR) report type.

      >>

      >> As you may recall, the consensus coming out of the DIME
      WG meeting

      >> in London was to support two report types:

      >>

      >> - Host -- Impacting requests with a Destination-Host AVP
      matching

      >> the host in the overload report (with the host implicitly


      >> determined from the Origin-Host AVP of the answer message
      carrying

      >> the overload report).

      >>

      >> - Realm -- Impacting 100% of the requests with a
      Destination-Realm

      >> AVP matching the realm in the overload report (with the
      realm

      >> implicitly determine from the Origin-Realm of the answer
      message

      >> carrying the overload report).

      >>

      >> The action Ben and I took was to come back with an
      opinion on

      >> whether RRR reports should also be supported.

      >>

      >> My summary of the discussion is that we recommend to NOT
      include

      >> RRR reports in the current version of the base DOIC
      draft.

      >>

      >> We still have some concerns with the granularity of
      control

      >> enabled by having just the two report types but the
      analysis of

      >> whether RRR reports are still needed can occur
      independent of the

      >> base DOIC draft.  If there is a determination that RRRs
      are needed

      >> in time to include in the base draft then it can be
      considered at

      >> that time.

      >>

      >> Based on this, I propose the following

      >>

      >> - Resolution to issue #23 is to remove RRR reports from
      the

      >> document. - Resolution to issue #55 is to add Realm
      reports

      >> (actually to redefine them per the above definition). -
      Resolution

      >> to issue #57 is that it no longer applies (as it deals
      with RRRs).

      >>

      >> There is also need for text describing the interaction
      between

      >> host and the realm reports.  I don't expect we will have
      consensus

      >> on this wording prior to the -02 draft being submitted.
      To this

      >> end, I'll open a new issue to deal with the need for
      wording on

      >> the interaction.

      >>

      >> Regards,

      >>

      >> Steve

      >>

      >>

      >>

      >>

      >>

      >> _______________________________________________

      >>

      >> DiME mailing list

      >>

      >> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>

      >>

      >> https://www.ietf.org/mailman/listinfo/dime

      >>

      >>

      >>

      >>

      >>

      >>

      >>

      >>
_________________________________________________________________________________________________________________________

      >>

     >>

      >>

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

      >

      >
_________________________________________________________________________________________________________________________

      >

      >

      >

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


_________________________________________________________________________________________________________________________

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.