Subject: [Dime] Issue #23 Proposed resolution

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 11:44:24 -0600

I propose the following resolution for issue 23:

Proposal -- Change the name of realm report. 

Proposed name - "Realm-Routed-Request" report.

Proposal -- Update all discussion on "Realm-Routed-Request" reports to
indicate that they apply only to requests targeted to a realm when there
is no destination-host AVP in the request.  Specifically, section 4.6
requires updating.

There is also a proposal to add a new report type to handle all
transactions to a realm.  This is addressed by ticket number 55.

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 24 Feb 2014 19:12:44 +0000

Hello,

I do not think we have agreed so far on the need to have two different reports (so called realm-routed and just realm).
Regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 18:44
To: [email-masked]
Subject: [Dime] Issue #23 Proposed resolution

Proposal - Change the name of realm report.

Proposal - Update all discussion on "Realm-Routed-Request" reports to indicate that they apply only to requests targeted to a realm when there is no destination-host AVP in the request.  Specifically, section 4.6 requires updating.

There is also a proposal to add a new report type to handle all transactions to a realm.  This is addressed by ticket number 55.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 13:39:32 -0600

Maria Cruz,

I thought you had asserted that there was a 3GPP requirement to have the
ability to have a realm report that control the total amount of traffic
sent to a realm.  There is certainly an IETF DOC requirement to this effect.

The proposal is to have three report types (or four depending on the
resolution of the per client host report discussion).

- Host report - Apply to all requests sent to a host.  The host is
indicated by the origin-host AVP in the answer message carrying the
report.  Can be generated by a server or by an agent acting as a
front-end to a group of servers.

- Realm-routed-request report - Applies to all requests sent to a realm
without a destination-host AVP in the request message.  Can be generated
by a server or by an agent acting as a front-end to a group of servers.

- Realm report - Applies to all requests sent to the realm, independent
of the presence or absence of a destination-host AVP in the request
message.  Can be generated by a server or an agent.  The method for
determining the realm state is out of scope for the DOIC document.

Steve

On 2/24/14 1:12 PM, Maria Cruz Bartolome wrote:
>
> Hello,
>
>  
>
> I do not think we have agreed so far on the need to have two different
> reports (so called realm-routed and just realm).
>
> Regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Steve Donovan
> *Sent:* lunes, 24 de febrero de 2014 18:44
> *To:* [email-masked]
> *Subject:* [Dime] Issue #23 Proposed resolution
>
>  
>
> indicate that they apply only to requests targeted to a realm when
> there is no destination-host AVP in the request.  Specifically,
> section 4.6 requires updating.
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Feb 2014 09:04:44 +0000

Steve,

The discussion started around some proposed use cases by Ulrich, and to my knowledge that discussion is not concluded.
Then we have not agreed (at least yet) on having a differentiation between realm and realm-routed.
Even more, as far as I understand the proposal it is related to the ability (by agent) to select the a server (in a farm, providing service to a realm) for new session establishment. This is something we discussed long time ago, and at that point in time we tend to agree that it was not required, but up to different applications to decide based on realm overload.
Enhancements could be done on top of this, but first we need to agree on the basic use cases.

I hope this clarifies
Cheers
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:40
To: [email-masked]
Subject: Re: [Dime] Issue #23 Proposed resolution

Maria Cruz,

I thought you had asserted that there was a 3GPP requirement to have the ability to have a realm report that control the total amount of traffic sent to a realm.  There is certainly an IETF DOC requirement to this effect.

The proposal is to have three report types (or four depending on the resolution of the per client host report discussion).

- Host report - Apply to all requests sent to a host.  The host is indicated by the origin-host AVP in the answer message carrying the report.  Can be generated by a server or by an agent acting as a front-end to a group of servers.

- Realm-routed-request report - Applies to all requests sent to a realm without a destination-host AVP in the request message.  Can be generated by a server or by an agent acting as a front-end to a group of servers.

- Realm report - Applies to all requests sent to the realm, independent of the presence or absence of a destination-host AVP in the request message.  Can be generated by a server or an agent.  The method for determining the realm state is out of scope for the DOIC document.

Steve

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 18:44
To: [email-masked]<mailto:[email-masked]>
Subject: [Dime] Issue #23 Proposed resolution

Regards,

Steve

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Feb 2014 09:16:03 +0000

Steve, MCruz,

lets go step by step.

I'm ok to conclude on #23 to do the renaming from "realm report type" to "realm-routed-request report type" and clarify that it applies to destination-host-less traffic.

Whether or not to introduce a 3rd report type of "realm" is out of scope of #23 and subject of #55.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 25, 2014 10:05 AM
To: [email-masked]
Subject: Re: [Dime] Issue #23 Proposed resolution

Steve,

I hope this clarifies
Cheers
/MCruz

Maria Cruz,

Steve

Regards,

Steve

DiME mailing list

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Feb 2014 09:33:16 +0000

Fine to agree

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: martes, 25 de febrero de 2014 10:16
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: [Dime] Issue #23 Proposed resolution

Steve, MCruz,

lets go step by step.

Ulrich

Steve,

I hope this clarifies
Cheers
/MCruz

Maria Cruz,

Steve

Regards,

Steve

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Feb 2014 07:22:22 -0600

I believe the other issue then is whether servers generate RRR reports.

Consider the most basic case where there are no agents.

 C1--\
 C2-------S
 C3--/

Is it not appropriate for a server, in this case, to be able to send RRRs?

In an agent case, the server sending the RRR gives the agent the ability
to generate an aggregated RRR the covers all servers for the
application.  So I guess, there would be a DOIC association between the
client and the agent use to transport the aggregated RRR and a DOIC
associate between the agent and the server used to transport the server
specific RRR.

Steve

On 2/25/14 3:33 AM, Maria Cruz Bartolome wrote:
>
> Fine to agree
>
>  
>
> *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
> *Sent:* martes, 25 de febrero de 2014 10:16
> *To:* Maria Cruz Bartolome; [email-masked]
> *Subject:* RE: [Dime] Issue #23 Proposed resolution
>
>  
>
> Steve, MCruz,
>
>  
>
> lets go step by step.
>
>  
>
>  
>
> I'm ok to conclude on #23 to do the renaming from "realm report type"
> to "realm-routed-request report type" and clarify that it applies to
> destination-host-less traffic.
>
>  
>
>  
>
> Whether or not to introduce a 3^rd report type of "realm" is out of
> scope of #23 and subject of #55.
>
>  
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Maria
> Cruz Bartolome
> *Sent:* Tuesday, February 25, 2014 10:05 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Dime] Issue #23 Proposed resolution
>
>  
>
> Steve,
>
>  
>
> The discussion started around some proposed use cases by Ulrich, and
> to my knowledge that discussion is not concluded.
>
> Even more, as far as I understand the proposal it is related to the
> ability (by agent) to select the a server (in a farm, providing
> service to a realm) for new session establishment. This is something
> we discussed long time ago, and at that point in time we tend to agree
> that it was not required, but up to different applications to decide
> based on realm overload.
>
> *Sent:* lunes, 24 de febrero de 2014 20:40
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Dime] Issue #23 Proposed resolution
>
>  
>
> Maria Cruz,
>
> I thought you had asserted that there was a 3GPP requirement to have
> the ability to have a realm report that control the total amount of
> traffic sent to a realm.  There is certainly an IETF DOC requirement
> to this effect.
>
> - Realm-routed-request report - Applies to all requests sent to a
> realm without a destination-host AVP in the request message.  Can be
> generated by a server or by an agent acting as a front-end to a group
> of servers.
>
> - Realm report - Applies to all requests sent to the realm,
> independent of the presence or absence of a destination-host AVP in
> the request message.  Can be generated by a server or an agent.  The
> method for determining the realm state is out of scope for the DOIC
> document.
>
> Steve
>
>     I do not think we have agreed so far on the need to have two
>     different reports (so called realm-routed and just realm).
>
>     Regards
>
>     /MCruz
>
>      
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     Proposal -- Update all discussion on "Realm-Routed-Request"
>     reports to indicate that they apply only to requests targeted to a
>     realm when there is no destination-host AVP in the request. 
>     Specifically, section 4.6 requires updating.
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Feb 2014 14:26:22 +0000

Steve,

see inline

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 25, 2014 2:22 PM
To: [email-masked]
Subject: Re: [Dime] Issue #23 Proposed resolution

 C1--\
 C2-------S
 C3--/

<Ulrich>no</Ulrich>

In an agent case, the server sending the RRR gives the agent the ability to generate an aggregated RRR the covers all servers for the application.
<Ulrich>the agent should aggregate received host-type reports and convert it into an RRR report</Ulrich>
  So I guess, there would be a DOIC association between the client and the agent use to transport the aggregated RRR
<Ulrich>yes</Ulrich>
and a DOIC associate between the agent and the server used to transport the server specific RRR
<Ulrich>server specific host-type report</Ulrich>
.

Steve

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: martes, 25 de febrero de 2014 10:16
To: Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dime] Issue #23 Proposed resolution

Steve, MCruz,

lets go step by step.

Ulrich

Steve,

I hope this clarifies
Cheers
/MCruz

Maria Cruz,

Steve

Regards,

Steve

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Feb 2014 08:48:32 -0600

Ulrich,

Please see inline.

Steve

On 2/25/14 8:26 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> see inline
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, February 25, 2014 2:22 PM
> *To:* [email-masked]
> */<Ulrich>no</Ulrich>/*
SRD> Then we have a bigger disconnect then I thought.  I'm pretty sure
that we had discussed the ability of a server to use what we are now
calling RRRs to be able to indicate that it does not want to take on new
sessions.  Host reports are used to control the mid-session traffic (for
session based applications like those used in the 3GPP PCC architecture). 

SRD> I would also assert that PCC is a case where there is a strong need
for the server to be able to say that it wants to reduce the number of
new session taken on so that the DRA in that architecture can properly
route sessions that generate new bindings.

SRD> So, to summarize, I believe that we DO have a requirement to allow
the server to send RRRs.

SRD> Maybe we need two types of RRRs, one that applies to a single
server and one that applies to the full realm.  Yes Ben, these do start
to sound like scopes :-) but this can also be addressed by either
creating separate report types or qualifying the RRR report.
>
>
> In an agent case, the server sending the RRR gives the agent the
> ability to generate an aggregated RRR the covers all servers for the
> application.
>
> */<Ulrich>the agent should aggregate received host-type reports and
> convert it into an RRR report</Ulrich>/*
>
SRD> This is what an agent would do to generate the proposed new "realm"
report.  I'm skeptical that an agent can make reasonable decisions about
what RRR report to generate based on host reports received.
>
>   So I guess, there would be a DOIC association between the client and
> the agent use to transport the aggregated RRR
>
> */<Ulrich>yes</Ulrich>/*
>
> */<Ulrich>server specific host-type report</Ulrich>/*
>
> .
>
> Steve
>
>     *To:* Maria Cruz Bartolome; [email-masked] <mailto:[email-masked]>
>     I'm ok to conclude on #23 to do the renaming from "realm report
>     type" to "realm-routed-request report type" and clarify that it
>     applies to destination-host-less traffic.
>
>      
>
>      
>
>     Whether or not to introduce a 3^rd report type of "realm" is out
>     of scope of #23 and subject of #55.
>
>      
>
>      
>
>     Ulrich
>
>      
>
>     *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext
>     Maria Cruz Bartolome
>     The discussion started around some proposed use cases by Ulrich,
>     and to my knowledge that discussion is not concluded.
>
>     Even more, as far as I understand the proposal it is related to
>     the ability (by agent) to select the a server (in a farm,
>     providing service to a realm) for new session establishment. This
>     is something we discussed long time ago, and at that point in time
>     we tend to agree that it was not required, but up to different
>     applications to decide based on realm overload.
>
>     I thought you had asserted that there was a 3GPP requirement to
>     have the ability to have a realm report that control the total
>     amount of traffic sent to a realm.  There is certainly an IETF DOC
>     requirement to this effect.
>
>     The proposal is to have three report types (or four depending on
>     the resolution of the per client host report discussion).
>
>     indicated by the origin-host AVP in the answer message carrying
>     the report.  Can be generated by a server or by an agent acting as
>     a front-end to a group of servers.
>
>     realm without a destination-host AVP in the request message.  Can
>     be generated by a server or by an agent acting as a front-end to a
>     group of servers.
>
>     independent of the presence or absence of a destination-host AVP
>     in the request message.  Can be generated by a server or an
>     agent.  The method for determining the realm state is out of scope
>     for the DOIC document.
>
>     Steve
>
>         reports to indicate that they apply only to requests targeted
>         to a realm when there is no destination-host AVP in the
>         request.  Specifically, section 4.6 requires updating.
>
>         There is also a proposal to add a new report type to handle
>         all transactions to a realm.  This is addressed by ticket
>         number 55.
>
>         Regards,
>
>         Steve
>
>          
>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Feb 2014 16:02:24 +0000

Hello,

I agree to what is being stated by Ulrich here.

Realm aggregated report is calculated by an agent, based on individual server host-reports. Then, it is up to each application to determine, based on requested traffic reduction, whether it is convenient or not to start new sessions. This is application dependent, since load/resources required by a session compared to mid session traffic is application dependent. A part from that, it could be up to some other criteria, like e.g. whether or not mid session traffic should be prioritized against new session creations, what would depend eventually on each application.

Regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: martes, 25 de febrero de 2014 15:49
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Issue #23 Proposed resolution

Ulrich,

Please see inline.

Steve

see inline

 C1--\
 C2-------S
 C3--/

Is it not appropriate for a server, in this case, to be able to send RRRs?
<Ulrich>no</Ulrich>
SRD> Then we have a bigger disconnect then I thought.  I'm pretty sure that we had discussed the ability of a server to use what we are now calling RRRs to be able to indicate that it does not want to take on new sessions.  Host reports are used to control the mid-session traffic (for session based applications like those used in the 3GPP PCC architecture).

SRD> I would also assert that PCC is a case where there is a strong need for the server to be able to say that it wants to reduce the number of new session taken on so that the DRA in that architecture can properly route sessions that generate new bindings.

SRD> So, to summarize, I believe that we DO have a requirement to allow the server to send RRRs.

SRD> Maybe we need two types of RRRs, one that applies to a single server and one that applies to the full realm.  Yes Ben, these do start to sound like scopes :-) but this can also be addressed by either creating separate report types or qualifying the RRR report.

In an agent case, the server sending the RRR gives the agent the ability to generate an aggregated RRR the covers all servers for the application.
<Ulrich>the agent should aggregate received host-type reports and convert it into an RRR report</Ulrich>
SRD> This is what an agent would do to generate the proposed new "realm" report.  I'm skeptical that an agent can make reasonable decisions about what RRR report to generate based on host reports received.

Steve

Steve, MCruz,

lets go step by step.

Ulrich

Steve,

I hope this clarifies
Cheers
/MCruz

Maria Cruz,

Steve

Regards,

Steve

DiME mailing list

DiME mailing list

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Feb 2014 14:08:17 -0600

I think limiting RRR reports to agents is too restrictive. I think any node that has knowledge of the overload state of the realm should be able to send an RRR report. I concur that this would typically be done by agents, but if an operator chooses to deploy servers that share overload state so that any given server can report on the realm, we should let them. It would be better to say that aggregate RRR reports should only be sent by nodes that actually have an aggregate knowledge of the realm.

I recognize it's hard for a server to know if it's knowledge is complete. Perhaps there are servers it doesn't know about. But I think this is also true of agents--perhaps there are other agents that have other servers behind them that the first agent doesn't know about. 

On Feb 25, 2014, at 10:02 AM, Maria Cruz Bartolome <[email-masked]> wrote:

> I’m ok to conclude on #23 to do the renaming from “realm report type” to “realm-routed-request report type” and clarify that it applies to destination-host-less traffic.
>  
>  
> Whether or not to introduce a 3rd report type of “realm” is out of scope of #23 and subject of #55.
>  
>  
> Ulrich
>  
> From: DiME [mailto:[email-masked]] On Behalf OfSteve Donovan
> Proposal – Change the name of realm report.  
> 
> Proposed name - “Realm-Routed-Request” report.
> 
> Proposal – Update all discussion on “Realm-Routed-Request” reports to indicate that they apply only to requests targeted to a realm when there is no destination-host AVP in the request.  Specifically, section 4.6 requires updating.
>