Subject: [Dime] OVLI: comments to 4.6

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 6 Dec 2013 12:10:41 +0000

Dear all,
 
here are comments to clause 4.6:
 
It has already been proposed to change the type of the OC-Report-Type AVP from Enumerated to Unsinged64 in order to avoid potential extensibility problems.  
In addition to that, I think that the purpose of the Report-Type is to let the reacting node know to which (future) request commands the overload treatment should apply:

For a host report-type the overload treatment should apply to all request commands for which
a) The request command's Application-ID matches the Application-Id of the OC-Report-Type AVP's encapsulating answer command and
b) The request command's Destination-Host is present and 
c) The request command's Destination-Host matches the Origin-Host of the OC-Report-Type AVP's encapsulating answer command

For a realm report-type the overload treatment should apply to all request commands for which
a) <see a) above> and
d) The request command's Destination-Host is absent and 
e) The request command's Destination Realm matches the Origin-Realm of the OC-Report-Type AVP's encapsulating answer command.

The proposal now is to assign individual bits of the Unsinged64 type to a), b), c), d), and e):

Proposed text:

   4.6 OC-Report-Type AVP

   The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contains a 64 bit flags field of a request
   command's characteristics.

   The following characteristics are defined in this document:

   APPLICATION_ID_MATCH (0x0000000000000001)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands with an Application-ID that matches the Application-Id of the OC-Report-Type AVP's
   encapsulating answer command.

   DESTINATION_HOST_PRESENT (0x0000000000000002)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands containing a Destination-Host AVP.

   DESTINATION_HOST_MATCH (0x0000000000000004)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   To those request commands with an Destination-Host AVP that matches the Origin-Host of the OC-Report-Type AVP's
   encapsulating answer command.

   DESTINATION_HOST_ABSENT (0x0000000000000008)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands not containing a Destination-Host AVP.

   DESTINATION_REALM_MATCH (0x0000000000000010)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands with an Destination-Host AVP that matches the Origin-Host of the OC-Report-Type AVP's
   encapsulating answer command.

   Combinations other than 
   1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HOST_MATCH
   and
   2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REALM_MATCH
   require a mutually agreed extension.

One extension required by 3GPP applications is the Overload Mitigation Differentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this, a new value would be needed e.g.
 
   ORIGIN_HOST_MATCH (0x0000000000000020)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands with an Origin-Host AVP that matches the Destination-Host of the OC-Report-Type AVP's
   encapsulating answer command.

With this extension the following additional combinations would be allowed:
3) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HOST_MATCH and ORIGIN_HOST_MATCH
and
4) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REALM_MATCH and ORIGIN_HOST_MATCH

Another potential extension is Diameter Agent Overload. To address this, a new value would be needed e.g.

   NEXT_HOP_MATCH (0x0000000000000040)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands sent to the same next hop the OC-Report-Type AVP's encapsulating answer command was received from.

Best regards
Ulrich

---

From: Jouni <[email-masked]>
Date: Fri, 6 Dec 2013 14:32:42 +0200

> It has already been proposed to change the type of the OC-Report-Type AVP from Enumerated to Unsinged64 in order to avoid potential extensibility problems.  

I do not see how changing the type to unsigned would help with the extensibility on
an assumption we create an IANA maintained registry for it. Unsigned64 will have
exactly the same issues as enumerated unless we define report type semantics to
something like what we have on OC-Feature AVP. How the receiver of the report type
reacts when it sees a flag bit that is does not understand? If the content and
handling  of the OC-OLR somehow depends on the unknown flag bit, the receiver has
no other choice than drop the OLR, since it cannot be sure how to handle the report
as a whole.

The only ways around I see here are:
a) you can extend report types when defining new applications
b) or when both ends have a mutually supported & advertised feature that maps
   to a report type (that has been defined after the publication of this 
   spec)

Other than those, IMHO, are just repackaging the issue into different form.

- Jouni

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 6 Dec 2013 14:17:50 +0000

Hi Jouni,

maybe that my proposal is just kind of repackaging. But still I think it is much clearer than the existing text, and you seem not to object.
Please consider accepting the proposed modification.

Best regards
Ulrich

-----Original Message-----
From: ext Jouni [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 1:33 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Fri, 6 Dec 2013 15:53:58 -0600

> c) The request command's Destination-Host matches the Origin-Host of the OC-Report-Type AVP's encapsulating answer command

We might consider whether a Host OLR would also apply to the selection of a next-hop peer, in cases where [B&C] were false. For example, if relay received a Host OLR from Server A, it might apply that OLR to requests it would ordinarily send to Server A, even if the client had not included a Destination-Host.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Sat, 7 Dec 2013 09:44:28 +0000

Hi Ulrich,

Instead of re-packing, I see your proposal as confusing or adding more implementation complexity to the exiting simple proposal of having just two Report-Type.
e.g. with your proposal, now the nodes have to validate if the combination of Report-Type flag is correct/allowed or not and perform the error handling if there is any discrepancy. 

Besides, I do not see the need for some obvious Report-Type e.g. "APPLICATION_ID_MATCH" since it is always present and/or implicit.
Same is the case with "DESTINATION_HOST_PRESENT" and "DESTINATION_HOST_MATCH". What is the use case for destination-host present but not match? In other words, the reacting node should use this type of report towards which node/realm?

I guess this time you need to convince me (at least) as why you think so many different Report-Types are needed and what is the issue with existing definition of Report-Type.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, December 06, 2013 7:48 PM
To: ext Jouni
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

Hi Jouni,

Best regards
Ulrich

-----Original Message-----
From: ext Jouni [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 1:33 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 11:15:06 +0200

> Please consider accepting the proposed modification.

I just stopped there because the provided text from my point of view
did not solve the core of the problem.

From my point of view, the feature announcement and new report types
need to be linked. Whether the report type is an enumerated or an
unsigned integer makes no difference.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 14:00:17 +0200

Folks,

We need a conclusion here so that I can actually write something
into the -01. How about the following (I try to reflect as many
points given here as possible):

1) The basic principle for the Report Type use is that only one
   OLR per report type is allowed unless the report type and the
   OLR reflecting the new report type define exact semantics how
   to differentiate between multiple OLRs with the same report
   type. In 3GPP context, for example, a report type with an AVP
   that identifies an APN could be such a differentiator.. and that
   would need a new report type where an implementation exactly
   knows to look for this additional AVP without guesswork or 
   fuzzy heuristics.

2) A new report type or a set of new report types require a new
   feature to be allocated/defined so that both endpoints know how
   to handle the new report type that was defined after the
   publication of the baseline specification. The handling of the
   new report types must be defined (along with the new AVPs it
   might need to be included into the OC-OLR AVP).

3) With 2) in place I do not care whether the OC-Report-Type is
   enumerated or unsigned (flag vector?). I still favour Enumerated
   myself as it forces the protocol designer to come up with a 
   cleaner design ;)

4) For the baseline we only define host and realm report types.
   We do not allow multiple OLRs with these report types i.e.
   single instances of OLRs with host and/or realm are allowed.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Dec 2013 12:24:34 +0000

Hi Nirav,
can you please point out what actually is confusing. I would have thougth that my proposal is more clear and precise as it exactly identifies when a given request matches the OLR (i.e. must undergo the throttling).

With regard to complexity there is no difference between checking the two allowed enumeration values 1 and 2 (current version) or the two allowed Unsigned64 values (0x0000000000000007) and (0x0000000000000019) (my proposal).

The main benefit I see with my proposal is the extensibility e.g.
One new value of   ORIGIN_HOST_MATCH (0x0000000000000020) for Overload Mitigation Differentiation per client rather than
Two new values of "host report with origin-host match" and realm-report with origin-host match".

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Saturday, December 07, 2013 10:44 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, December 06, 2013 7:48 PM
To: ext Jouni
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

Hi Jouni,

Best regards
Ulrich

-----Original Message-----
From: ext Jouni [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 1:33 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

- Jouni

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 9 Dec 2013 12:56:12 +0000

Ulrich,

Defining a bit "APPLICATION_ID_MATCH" and not having a use case when this bit is set to "0" (at least in the context of the current draft) is confusing to me. Same is the case with some other bits you have proposed.

In summary, I do not see any issue with the current ReportType. 
For the extensibility, we have to deal with it anyway when we have corresponding use case in 3GPP or in IETF. In my view, defining the ReportType with some assumption of its extensibility is confusing since those use cases are not discussed here yet.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, December 09, 2013 5:55 PM
To: Nirav Salot (nsalot); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Nirav,

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Saturday, December 07, 2013 10:44 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, December 06, 2013 7:48 PM
To: ext Jouni
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

Hi Jouni,

Best regards
Ulrich

-----Original Message-----
From: ext Jouni [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 1:33 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Dec 2013 13:38:27 +0000

Hi Nirav,

in the end its a matter of taste, and I definitly prefer the Unsigned64 approach.

Please note: The Enumerated approach also has a value (0 Reserved) without use case. And there is confusing text e.g. "...should apply to requests that the reacting node knows will reach the overloaded node." 
How would the reacting node know that a request will actually reach the overloaded node? And even if it knows this, wouldn't the overload treatment apply only to those requests that match the application-id from the answer?

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Monday, December 09, 2013 1:56 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, December 09, 2013 5:55 PM
To: Nirav Salot (nsalot); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Nirav,

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Saturday, December 07, 2013 10:44 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, December 06, 2013 7:48 PM
To: ext Jouni
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

Hi Jouni,

Best regards
Ulrich

-----Original Message-----
From: ext Jouni [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 1:33 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Dec 2013 16:18:51 -0600

It's probably also worth adding some guidance on when it makes sense to define a new report type. For example, if I want to add a new AVP that can be safely ignored by a recipient that doesn't understand it, I probably don't need a new report type.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 10 Dec 2013 05:15:29 +0000

Jouni,

I am fine with the principles you have mentioned below for Report Type.
I also prefer to use enumerated type for this AVP if that does not risk the extendibility of this AVP.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Monday, December 09, 2013 5:30 PM
To: [email-masked] list
Subject: [Dime] Conclusion for the Report Type

Folks,

We need a conclusion here so that I can actually write something into the -01. How about the following (I try to reflect as many points given here as possible):

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 09:28:59 +0200

Good point.

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 09:57:13 +0200

> I also prefer to use enumerated type for this AVP if that does not risk the extendibility of this AVP.

Ok. Good.

- Jouni

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 13 Dec 2013 09:28:08 +0000

Hello Ulrich, all,

I agree with Nirav, I think in the base IETF draft we need to keep what is required for the use cases identified so far, (as long as ReportType is extensible).

Therefore I think that DESTINATION_HOST_MATCH and DESTINATION_REALM_MATCH are enough in the draft.

>   APPLICATION_ID_MATCH (0x0000000000000001)
Agreement for the baseline is to infer this always from the Diameter encapsulating message. Therefore, this is always done, no reason to add a ReportType for this.
>   DESTINATION_HOST_PRESENT (0x0000000000000002)
What we need to know if whether overload-report shall apply for either HOST_MATCH or REALM_MATCH. 
This value is included into HOST_MATCH, then I do not see a reason to have it as an independent value.

>   DESTINATION_HOST_MATCH (0x0000000000000004)
Fine, I think this is required

>   DESTINATION_HOST_ABSENT (0x0000000000000008)
This value is included into REALM_MATCH. Any reason to have it as an independent value? 

>   DESTINATION_REALM_MATCH (0x0000000000000010)
Fine, I think this is required

About decision on whether it should be Unsigned or Enumerated, not sure which one could be best, I then to agree with Jouni that both could be valid as long as we need to define new values on application documentation, explaining expected behavior.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 09 de diciembre de 2013 14:38
To: ext Nirav Salot (nsalot); ext Jouni
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

Hi Nirav,

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Monday, December 09, 2013 1:56 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Ulrich,

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, December 09, 2013 5:55 PM
To: Nirav Salot (nsalot); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Nirav,

Best regards
Ulrich

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:[email-masked]] 
Sent: Saturday, December 07, 2013 10:44 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni
Cc: [email-masked]
Subject: RE: [Dime] OVLI: comments to 4.6

Hi Ulrich,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, December 06, 2013 7:48 PM
To: ext Jouni
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

Hi Jouni,

Best regards
Ulrich

-----Original Message-----
From: ext Jouni [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 1:33 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 13 Dec 2013 12:53:54 +0200

> Therefore I think that DESTINATION_HOST_MATCH and DESTINATION_REALM_MATCH are enough in the draft.

Ok.

> About decision on whether it should be Unsigned or Enumerated, not sure which one could be best, I then to agree with Jouni that both could be valid as long as we need to define new values on appli…

Ok. My preference is still enumerated, mainly because it prevents
designing do_everything_and_a_bit_more OLRs. A report type and a 
matching OLR for a single purpose.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 13 Dec 2013 11:44:57 +0000

Would it be acceptable to define enumeration values for Host Report to be 7 and for Realm Report to be 25 and add some informative text that explains the intention?

Although its ok to signal only one of two values, the reporting node must do three of five checks.

Ulrich   

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Friday, December 13, 2013 11:54 AM
To: Maria Cruz Bartolome
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.6

Ok.

- Jouni

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 16 Dec 2013 14:36:18 +0000

Hi Jouni

I am also fine for the statements you proposed.

My understanding for 4) about instances is the following 
- when an OLR with host report type is present in a message; it is the only OLR instance with this report type
- same for OLR with a realm report type
- but you may have an OLR host report type and another OLR with realm report type in the same message.

Is my understanding correct?

Best regards 

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : mardi 10 décembre 2013 08:57
À : Nirav Salot
Cc : [email-masked] list
Objet : Re: [Dime] Conclusion for the Report Type

Ok. Good.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 16 Dec 2013 18:06:47 +0200

> Is my understanding correct?

Yes.

- Jouni

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 16 Dec 2013 17:04:25 +0000

Hello,

I agree on the principles.
Enumerated is fine for me as well.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 09 de diciembre de 2013 13:00
To: [email-masked] list
Subject: [Dime] Conclusion for the Report Type

Folks,

- Jouni

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 16 Dec 2013 17:52:54 +0000

Hi 

About Enumerated versus unsigned (flag vector), Lionel is in favour of using unsigned (flag vector) due to the issue  for adding a new emulated value in the future to the existing one, creating backward compatibility. In  3GPP CT4 it is the unsigned (flag vector rule we apply for new AVPs, so I would prefer to be consistent by using the same rule. It would be good to have Lionel's view on this.

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : lundi 16 décembre 2013 18:04
À : Jouni Korhonen; [email-masked] list
Objet : Re: [Dime] Conclusion for the Report Type

Hello,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: lunes, 09 de diciembre de 2013 13:00
To: [email-masked] list
Subject: [Dime] Conclusion for the Report Type

Folks,

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 16 Dec 2013 22:08:18 +0200

Hi,

My take is that a flag field would have exactly the same issues as enumerated if it used in a similar manner as enumerated. 

If new enumerated values are only used and _included_ into OC-Report-Type when both ends are known to support it, there is no issue. And that is, for example, exactly one reason we have the OC-Feature-Vector for. All we need to do is to make sure that (a set of) new report types in future specifications also imply a definition of a new feature vector flag. 

- Jouni