Subject: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

From: "dime issue tracker" <[email-masked]>
Date: Tue, 04 Feb 2014 08:47:50 -0000

#30: OC-Supported-Features AVP in answer messages

 According to the current feature advertisement/negotiation mechanism in
 the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP
 in answer messages to indicate their supported OC features to the reacting
 DOIC endpoint.
 The author of this document believes that  the best a reacting node can do
 with such information is to ignore it, and therefore proposes to allow
 reporting nodes not to insert OC-Supported-Features AVPs in answer
 messages.
 Currently only one feature is defined (OLR_DEFAULT_ALGO).
 A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other
 feature is only interested in receiving/not receiving OC-OLR AVPs from
 reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates
 support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving
 an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:

 a) There is no overload
 b) DOIC is not supported

 The reacting DOIC endpoint does not need to differentiate between these
 two cases as the behavior (do not throttle) is the same in both cases.
 The -01 draft says in  clause 4.1:
    If there is no single matching
    capability the reacting node MUST act as if it does not implement
    DOIC and cease inserting any DOIC related AVPs into any Diameter
    messages with this specific reacting node.

 This however is inconsistent.
 The reacting node that ceases sending DOIC related AVPs would never
 recognize when the server is upgraded to support DOIC.
 Subsequent requests (not including DOIC related AVPs) may take a different
 path towards the server and on that path there may be an agent that
 supports DOIC (with a match of supported features) and could take the role
 of the reporting DOIC endpoint; but the agent cannot take this role since
 the reacting node (although supporting DOIC) ceased sending of OC-
 Supported-Features AVPs.
 In summary: As long as no extension feature is defined within  draft-ietf-
 dime-ovli  (i.e. never, since extensions will  be defined in other
 drafts), there is no need for draft-ietf-dime-ovli  to mandate or even
 describe inclusion of OC-Supported-Features AVP in answer messages.

-- 
--------------------------------------+--------------------------
 Reporter:  [email-masked]  |      Owner:  Ulrich Wiehe
     Type:  defect                    |     Status:  new
 Priority:  major                     |  Milestone:
Component:  draft-docdt-dime-ovli     |    Version:
 Severity:  Active WG Document        |   Keywords:
--------------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/30>
dime <http://tools.ietf.org/wg/dime/>

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 15:01:04 +0000

I think that there is actually an issue here but the proposed way to solve it is not the correct one.
The initial idea was to be able to use the same overload report with several algorithms. So the OLR was somehow only meaningful along with the OC-Feature-Vector AVP.

But because the OC-Feature-Vector AVP is defined as a set of flags, it is not possible to say that this OLR is to be used with only one given algo when more than one is defined (as the bit flags will advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to indicate the abatement to perform.

As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.

It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.

Lionel 

-----Message d'origine-----
De : dime issue tracker [mailto:[email-masked]] 
Envoyé : mardi 4 février 2014 09:48
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : [dime] #30: OC-Supported-Features AVP in answer messages

 a) There is no overload
 b) DOIC is not supported

_________________________________________________________________________________________________________________________

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.

---

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

Dear Lionel,

thank you for your response.

If I correctly understand, the principles would be:
1. Sending OC-Supported-Features in answer messages is syntactically optional.
2. When the reacting node does only support OLR_DEFAULT_ALGO , the reporting node should not insert an OC-Supported-Features AVP in the answer message.
3. When the reporting node does only support OLR_DEFAULT_ALGO, it should not insert an OC-Supported-Features AVP in the answer message.
4. A reacting node that supports only OLR_DEFAULT_ALGO can safely ignore OC-Supported-Features AVPs received in answer messages.
5. A reacting node that supports only OLR_DEFAULT_ALGO can safely ignor all extensions received in an OC-OLR.
6. When a new feature is introduced, the spec introducing the new feature must define the details to ensure interoperability of nodes supporting the new feature with nodes that do not support the new feature (taking into account that nodes not supporting the new feature act according to the principles 1.-5.).

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, February 04, 2014 4:01 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Lionel 

-----Message d'origine-----

 a) There is no overload
 b) DOIC is not supported

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

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 16:51:06 +0000

Hi Ulrich,

For the point 2 and 3, the difference between the "Should" and the "May" is quite subtle here and is for me only an implementation option.

For 4 and 5, ok if the node only supports the default algo. In other words, only the OLR matters for nodes supporting only the default algo. The rest is purely for information and can be safely ignored.

For 6, if the new feature consists in a new algo, it would mean defining a new dedicated OLR AVP. So nodes supporting only the default algo will ignore any unknown AVP if received.

Regards,

Lionel

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : mardi 4 février 2014 17:04
À : MORAND Lionel IMT/OLN; [email-masked]
Objet : RE: [dime] #30: OC-Supported-Features AVP in answer messages

Dear Lionel,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, February 04, 2014 4:01 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Lionel 

-----Message d'origine-----

 a) There is no overload
 b) DOIC is not supported

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 5 Feb 2014 04:35:06 +0000

But can the reacting node make use of Supported-Feature/OC-Feature-Vector AVP, received in answer message?
I guess not.

Based on the Supported-Feature/OC-Feature-Vector AVP received the reporting node will generate OC-OLR or new OLR defined in future (for different abatement algorithm). 
So in general, it seems to me that the Supported-Feature/OC-Feature-Vector AVP is not useful for the reacting node.
If so, it can be removed.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 04, 2014 8:31 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Lionel 

-----Message d'origine-----

 According to the current feature advertisement/negotiation mechanism in  the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP  in answer messages to indicate their supported OC features to the reacting  DOIC endpoint.
 The author of this document believes that  the best a reacting node can do  with such information is to ignore it, and therefore proposes to allow  reporting nodes not to insert OC-Supported-Features AVPs in answer  messages.
 Currently only one feature is defined (OLR_DEFAULT_ALGO).
 A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other  feature is only interested in receiving/not receiving OC-OLR AVPs from  reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates  support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving  an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:

 a) There is no overload
 b) DOIC is not supported

 The reacting DOIC endpoint does not need to differentiate between these  two cases as the behavior (do not throttle) is the same in both cases.

 This however is inconsistent.
 The reacting node that ceases sending DOIC related AVPs would never  recognize when the server is upgraded to support DOIC.
 Subsequent requests (not including DOIC related AVPs) may take a different  path towards the server and on that path there may be an agent that  supports DOIC (with a match of supported features) and could take the role  of the reporting DOIC endpoint; but the agent cannot take this role since  the reacting node (although supporting DOIC) ceased sending of OC-  Supported-Features AVPs.
 In summary: As long as no extension feature is defined within  draft-ietf-  dime-ovli  (i.e. never, since extensions will  be defined in other  drafts), there is no need for draft-ietf-dime-ovli  to mandate or even  describe inclusion of OC-Supported-Features AVP in answer messages.

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.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 5 Feb 2014 08:03:55 +0000

Hi Loinel,

it seems that we can safely remove OC-Supported-Feature AVP from answer messages in the draft-ietf-dime-ovli (which does not define extensions to itself). This does not mean that a future extension cannot (re)-introduce it when needed. It also does not mean that reporting nodes are not allowed to include it in answer messages as long as answer messages have a *[AVP].

Best regards
Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 04, 2014 5:51 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: RE: [dime] #30: OC-Supported-Features AVP in answer messages

Hi Ulrich,

Regards,

Lionel

-----Message d'origine-----

Dear Lionel,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, February 04, 2014 4:01 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Lionel 

-----Message d'origine-----

 a) There is no overload
 b) DOIC is not supported

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 12:04:22 +0200

> I think that there is actually an issue here but the proposed way to solve it is not the correct one.

Agree.

> The initial idea was to be able to use the same overload report with several algorithms. So the OLR was somehow only meaningful along with the OC-Feature-Vector AVP.

The initial idea was to go on lines of RFC5447.

> But because the OC-Feature-Vector AVP is defined as a set of flags, it is not possible to say that this OLR is to be used with only one given algo when more than one is defined (as the bit flags wi…

My intention was always allow:

  client announces  ABC
  server supports    BCD
  server announced only  e.g. C since it is common
  alternatively server announced nothing and then the default applies

> As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedica…

Bah. OLR should work for additional abatement algorithms
IF we agree that the OLR is align with the announced
abatement algorithm.. 

> It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.

It is already today if you only support the default, right.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 12:09:05 +0200

> it seems that we can safely remove OC-Supported-Feature AVP from answer messages in the draft-ietf-dime-ovli (which does not define extensions to itself). This does not mean that a future extension…

Not so fast. Leaving OC-Supported-Feature AVP away from the 
answer is already supported by the -01. So there is nothing
to fix in that part.

The thing that need to be fixed is the inconsistency on you
pointed out which would make reacting node not to send any
DOIC AVPs.

- JOuni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 7 Feb 2014 13:54:40 +0000

See inline

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 11:09 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Not so fast. Leaving OC-Supported-Feature AVP away from the 
answer is already supported by the -01. So there is nothing
to fix in that part.
<Ulrich> it seems you agree that 
a) reporting nodes that only support OLR_DEFAULT_ALGO are not required to send OC-Supported-Features AVP in answer messages (of course they may if there is the *[AVP])
b) reacting nodes that only support  OLR_DEFAULT_ALGO can safely ignore OC-Supported-Features AVPs received in answer messages
c) behavior of the reacting node that only supports OLR_DEFAULT_ALGO does not depend on presence/absence of OC-Supported-Features AVPs in received answer messages
if that's agreed, why not say so clearly in the draft?
(the clear way to say so is to remove this AVP from answers. </Ulrich>

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 9 Feb 2014 14:42:51 +0200

> a) reporting nodes that only support OLR_DEFAULT_ALGO are not required to send OC-Supported-Features AVP in answer messages (of course they may if there is the *[AVP])

As I said this is already in the draft, thus ok. We just need to
clarify the use of OC-Supported-Features, remove the contradicting
text and clarify that the absence of the OC-Supported-Features
equals to the OLR_DEFAULT_ALGO (currently it only states that for
the OC-Feature-Vector).

- JOuni

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 10 Feb 2014 08:03:25 +0000

Hi all

My own remarks

- my trend is that the reacting and reporting node exchange their capabilities so that each is aware of what the other supports. This also may allow the reporting node to indicate the reacting node which capabilities it has selected among  those proposed by the reacting  node. In 3GPP, there is a similar mechanism  commonly used with supported features in the requests and in the answer and this has not rose issues. 
 
- Ulrich is proposing  an optimization  to avoid to send the OC-Supported-features AVP in the answer, as currently we have only one algo (the default one).  I also assume that no ORL is sent in this answer (Reporting node being not in an overloaded situation). So even if the reacting node does not know immediately if the reporting node is supporting DOIC with default algo or not, the reacting node  will learn this later when the reporting node will send its first  OC-OLR AVP which, with the current draft, is only used with the default algo. So this optimization is applicable. Nevertheless, as mentioned for 3GPP where a similar mechanism,  3GGP has not felt the requirement to introduce such an optimization for some cases, so this optimization may be not so a strong requirement.

- then for the future, I would rather think that if new algos or new features adding extensions to an algo, we will come back to the use of the OC Supported Features in requests and answers. I am not sure that we should always rely on new OLR AVPs for this as the existing OC-OLR AVP can be reused. 

- so I am not against to have no OC-Supported feature in the answer, but I would also allow it to be present(so a MAY) in the answers, which is more future safe.   
  
- by the way, is the default algorithm mandatory? From the current draft as the default algo is the only algo that a reacting node can advertise, so  the answer is currently yes. But, for future, I think we were in favor to have at least a common supported algorithm by any entity supporting DOIC for interoperability reasons. I have not seen this written; I think it should be clarified in the draft.

Best regards

JJacques   

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : vendredi 7 février 2014 14:55
À : ext Jouni Korhonen
Cc : [email-masked]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

See inline

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 11:09 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

- JOuni

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 11:15:31 +0000

Hi Jouni,

[LM] The issue if when you have more than one algo (let say 2). There is no way for the reporting node to indicate the algo to use with the OLR sent in the answer using the OC-Feature-Vector. The only info that you could have is "use either one or the other".
The simpliest way would be to define a new AVP when you want to support more than the default algo. If you want to rely on the same OLR with another algo, you should have a way to indicate the algo to use with the given OLR. 

[LM] Right. No issue here.

-----Message d'origine-----
De : Jouni Korhonen [mailto:[email-masked]] 
Envoyé : vendredi 7 février 2014 11:04
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Agree.

  client announces  ABC
  server supports    BCD

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 10 Feb 2014 13:23:59 +0200

> [LM] The issue if when you have more than one algo (let say 2). There is no way for the reporting node to indicate the algo to use with the OLR sent in the answer using the OC-Feature-Vector. The o…

This we can fix (and I personally would like to fix). The reporting node
announces in its OC-Feature-Vector the selected common algorithm for the
sent OLR. We had this at some point of time, btw.

> The simpliest way would be to define a new AVP when you want to support more than the default algo. If you want to rely on the same OLR with another algo, you should have a way to indicate the algo…

I recall there was a strong arguments against algorithm types in OLRs..

- Jouni

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 11:36:38 +0000

-----Message d'origine-----
De : Jouni Korhonen [mailto:[email-masked]] 
Envoyé : lundi 10 février 2014 12:24
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

[LM] Acceptable! So in answer including the OLR, the OC-Feature-Vector MAY be used (when present) to indicate the algo to use, algo part of the common algos between the reporting node and the reacting node.

[LM] I was not proposing such idea :)

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 09:07:34 -0600

I'll attempt to summarize where we are on this.  If this is agreed to
then the necessary changes would be made to the -01 draft.  Some of this
is already in the draft, some of it will require changes.

- The draft already makes it optional for the reporting node to include
the OC-Supported-Features AVP in answer messages - No change required here.

- A reporting node must choose the overload abatement algorithm to be
sent to a reacting node from the set of abatement algorithms included in
the OC-Supported-Features AVP received in the request message.

- If the reporting node sends an OC-OLR AVP and there is no
OC-Supported-Features AVP then the abatement algorithm used by the
reacting node must be loss.

- The reporting node may include the OC-Supported-Features AVP with the
loss algorithm indicated in the OC-Feature-Vector AVP.

- If the reporting node wants the reacting node to apply an algorithm
other then loss, the reacting node must include the
OC-Supported-Features AVP with a single algorithm indicated in the
OC-Feature-Vector AVP.

- New abatement algorithm extensions may use and extend the existing
OC-OLR AVP.  The new algorithms may also create a new overload report
AVP if that makes the most sense.

- The loss algorithm is and always will be the mandatory to implement
algorithm.  Or it will be until a new RFC is published that changes the
mandatory to implement algorithm.

Steve

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 10 Feb 2014 15:44:56 +0000

Hi Steve

Thanks to have summarize this topic. I agree with your various statements that reflect in particular my own comments.

About mandatory for the default (loss) algorithm, effectively we  need this for interoperability. Cannot it be stated in the draft? Future RFCs will have to be compatible with this .

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 10 février 2014 16:08
À : [email-masked]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I'll attempt to summarize where we are on this.  If this is agreed to then the necessary changes would be made to the -01 draft.  Some of this is already in the draft, some of it will require changes.

- The draft already makes it optional for the reporting node to include the OC-Supported-Features AVP in answer messages - No change required here.

- A reporting node must choose the overload abatement algorithm to be sent to a reacting node from the set of abatement algorithms included in the OC-Supported-Features AVP received in the request message.

- If the reporting node sends an OC-OLR AVP and there is no OC-Supported-Features AVP then the abatement algorithm used by the reacting node must be loss.

- The reporting node may include the OC-Supported-Features AVP with the loss algorithm indicated in the OC-Feature-Vector AVP.

- If the reporting node wants the reacting node to apply an algorithm other then loss, the reacting node must include the OC-Supported-Features AVP with a single algorithm indicated in the OC-Feature-Vector AVP.

- New abatement algorithm extensions may use and extend the existing OC-OLR AVP.  The new algorithms may also create a new overload report AVP if that makes the most sense.

- The loss algorithm is and always will be the mandatory to implement algorithm.  Or it will be until a new RFC is published that changes the mandatory to implement algorithm.

Steve
On 2/10/14 5:36 AM, [email-masked]<mailto:[email-masked]> wrote:

-----Message d'origine-----

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

On Feb 10, 2014, at 1:15 PM, <[email-masked]><mailto:[email-masked]> wrote:

Hi Jouni,

abatement algorithm..

- Jouni

-----Message d'origine-----

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

On Feb 4, 2014, at 5:01 PM, [email-masked]<mailto:[email-masked]> wrote:

Agree.

 client announces  ABC

 server supports    BCD

abatement algorithm..

- Jouni

Lionel

-----Message d'origine-----

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

DOIC endpoint.

messages.

a) There is no overload

b) DOIC is not supported

Supported-Features AVPs.

--

Reporter:  [email-masked]<mailto:[email-masked]>  |      Owner:  Ulrich Wiehe

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/30><http://trac.tools.ietf.org/wg/dime/trac/ticket/30>

dime <http://tools.ietf.org/wg/dime/><http://tools.ietf.org/wg/dime/>

Thank you.

DiME mailing list

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

Thank you.

Thank you.

DiME mailing list

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

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 09:57:47 -0600

I agree it needs to be stated in the draft.

Steve

On 2/10/14 9:44 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi Steve
>
>  
>
> Thanks to have summarize this topic. I agree with your various
> statements that reflect in particular my own comments.
>
>  
>
> About mandatory for the default (loss) algorithm, effectively we  need
> this for interoperability. Cannot it be stated in the draft? Future
> RFCs will have to be compatible with this .
>
>  
>
> Best regards
>
>  
>
> JJacques   
>
>  
>
>  
>
>  
>
> *De :*DiME [mailto:[email-masked]] *De la part de* Steve Donovan
> *Envoyé :* lundi 10 février 2014 16:08
> *À :* [email-masked]
> *Objet :* Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer
> messages
>
>  
>
> then the necessary changes would be made to the -01 draft.  Some of
> this is already in the draft, some of it will require changes.
>
> - The draft already makes it optional for the reporting node to
> include the OC-Supported-Features AVP in answer messages - No change
> required here.
>
> sent to a reacting node from the set of abatement algorithms included
> in the OC-Supported-Features AVP received in the request message.
>
> - The reporting node may include the OC-Supported-Features AVP with
> the loss algorithm indicated in the OC-Feature-Vector AVP.
>
> algorithm.  Or it will be until a new RFC is published that changes
> the mandatory to implement algorithm.
>
> Steve
>
>     Cc : [email-masked] <mailto:[email-masked]>
>
>     On Feb 10, 2014, at 1:15 PM, <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>
>         Hi Jouni,
>
>          
>
>         Cc : [email-masked] <mailto:[email-masked]>
>
>         On Feb 4, 2014, at 5:01 PM, [email-masked] <mailto:[email-masked]> wrote:
>
>          
>
>             Cc : [email-masked] <mailto:[email-masked]>
>
>             Reporter:  [email-masked] <mailto:[email-masked]>  |      Owner:  Ulrich Wiehe
>
>             Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/30> <http://trac.tools.ietf.org/wg/dime/trac/ticket/30>
>
>             dime <http://tools.ietf.org/wg/dime/> <http://tools.ietf.org/wg/dime/>
>
>              
>
>              
>
>             [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 16:46:23 +0000

Thank you for the summary.

I'm fine with all the bullets! :)

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 10 février 2014 16:58
À : [email-masked]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Steve

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 10 février 2014 16:08
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Steve

-----Message d'origine-----

Hi Jouni,

abatement algorithm..

- Jouni

-----Message d'origine-----

Agree.

 client announces  ABC

 server supports    BCD

abatement algorithm..

- Jouni

Lionel

-----Message d'origine-----

DOIC endpoint.

messages.

a) There is no overload

b) DOIC is not supported

Supported-Features AVPs.

--

Thank you.

DiME mailing list

Thank you.

Thank you.

DiME mailing list

DiME mailing list

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 11 Feb 2014 00:15:22 +0200

+1

On Feb 10, 2014, at 6:46 PM, [email-masked] wrote:

> I'm fine with all the bullets! J
>  
> Lionel
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Feb 2014 18:14:29 -0600

I don't quite agree with where I think this thread is going, on two points:

1) I want the reacting node to be able to learn if a (potentially) reporting node supports DOIC, even when that node is not in overload. I don't want to specify any particular behavior for that knowledge, but I suspect implementations may want to treat DOIC compliant servers in some way differently than they do non-DOIC servers. For example, I might have a configured rate limit for non-DOIC peers, but use a higher (or no) limit for peers that are known to support DOIC (and can thus speak for themselves.)

2) It's clumsy to have to look at an external (to OC-OLR) AVP to find out the algorithm. I think the actual algorithm for a particular report should be indicated in OC-OLR, not OC-Supported-Features at the root of the message.

Now, separate from those points, I think we should consider whether it's okay for a reporting nodes to switch algorithms mid-stream, vs pick an algorithm and stick with it. Right now, I think we effectively allow a reporting node to send an OLR for one algorithm in one answer, then another algorithm in the next, even for the same reacting node. If so, we need to define what it means when that happens.

For example, if I receive an OLR with the "loss" algorithm, and another with the "rate" algorithm from the same server, does the second replace the first? Do I now have two overload state entries that I need to "stack"?

Thanks!

Ben.

On Feb 10, 2014, at 9:07 AM, Steve Donovan <[email-masked]> wrote:

>> De : Jouni Korhonen [
>> mailto:[email-masked]
>> ] 
>> Cc : 
>> [email-masked]
>> On Feb 10, 2014, at 1:15 PM, 
>> <[email-masked]>
>>  wrote:
>> 
>> 
>>> Hi Jouni,
>>> 
>>> 
>>> De : Jouni Korhonen [
>>> mailto:[email-masked]
>>> ] 
>>> Cc : 
>>> [email-masked]
>>> On Feb 4, 2014, at 5:01 PM, 
>>> [email-masked]
>>>  wrote:
>>> 
>>> 
>>>> De : dime issue tracker [
>>>> mailto:[email-masked]
>>>> ] 
>>>> Cc : 
>>>> [email-masked]
>>>> Reporter:  
>>>> [email-masked]
>>>>   |      Owner:  Ulrich Wiehe
>>>> Ticket URL: 
>>>> <http://trac.tools.ietf.org/wg/dime/trac/ticket/30>
>>>> 
>>>> dime

---

From: <[email-masked]>
Date: Tue, 11 Feb 2014 10:06:47 +0000

On 1), the reacting node will know that the server is DOIC-enabled when receiving the Supported-Features AVP, whatever the content of this AVP. When no OLR is sent, I think that there is nothing preventing a reporting node to announce all

On 2), honestly, I don't see the need for trying to keep a single AVP for all the possible abatements, especially if we are saying that the overload control is defined per application.
I think that there is value to try to reuse the same algo across application but not so try to reuse the same AVP across algos.

I do not foresee 1000 different algos defined for Diameter systems. And if it is, defining one OC-OLR AVP per algo is not an issue. We are not running out of AVP codes. The AVP code itself is sufficient to indicate the algo to use i.e. "this is an overload report for algo x". And each application will explain anyhow how to use this overload report.

The main conclusions would be to be able to:
- Get rid of the OC-Supported-Features AVP in answer containing an OC-OLR AVP.
- get rid of the sequence number in the OC-Supported-Feature AVP in all the requests and in the answer when the OC-Supported-features AVP is including for capabilities discovery.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mardi 11 février 2014 01:14
À : Steve Donovan
Cc : [email-masked] list
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Thanks!

Ben.

---

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

> On 1), the reacting node will know that the server is DOIC-enabled when receiving the Supported-Features AVP, whatever the content of this AVP. When no OLR is sent, I think that there is nothing pr…

I'm confused. I thought the thread was saying that sending the OC-Supported-Features AVP in an answer would be optional. Did I misunderstand? 

> I do not foresee 1000 different algos defined for Diameter systems. And if it is, defining one OC-OLR AVP per algo is not an issue. We are not running out of AVP codes. The AVP code itself is suffi…

If we don't do this in a consistent way across applications, then application-independent relays will not be able to participate.

> - Get rid of the OC-Supported-Features AVP in answer containing an OC-OLR AVP.

Disagree for the reasons stated. I want a a consistent, single AVP that I can use to tell if the server supports DOIC. The code I envision wouldn't bother looking for OC-OLR if OC-Supported-Features was absent. It costs nothing to put it in, and it makes life much easier on the recipient.

> - get rid of the sequence number in the OC-Supported-Feature AVP in all the requests and in the answer when the OC-Supported-features AVP is including for capabilities discovery.

Have we also agreed to require OC-Supported-Feature in every request?

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Feb 2014 15:31:36 +0000

Ben,
please see inline.

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Tuesday, February 11, 2014 1:14 AM
To: Steve Donovan
Cc: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

1) I want the reacting node to be able to learn if a (potentially) reporting node supports DOIC, even when that node is not in overload. I don't want to specify any particular behavior for that knowledge, but I suspect implementations may want to treat DOIC compliant servers in some way differently than they do non-DOIC servers. For example, I might have a configured rate limit for non-DOIC peers, but use a higher (or no) limit for peers that are known to support DOIC (and can thus speak for themselves.)
<Ulrich>sounds like a new requirement; where does it come from? I would have thought that there is no need to distinguish between
a) DOIC not supported and therefore no traffic reduction requested, and
b) DOIC supported, but not in overload and therefore no traffic reduction requested</Ulrich> 

<Ulrich>I agree</Ulrich>

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Feb 2014 09:55:27 -0600

> b) DOIC supported, but not in overload and therefore no traffic reduction requested</Ulrich> 

At one point, I thought we agreed as a group that a reacting node should be able to identify if a (potential) reporting node supported the mechanism. But in any case, we have a requirement that the mechanism must work in a mixed environment, where some nodes support it and some don't. It's much _easier_ to meet that requirement if we can tell what nodes support it and what don't. 

In general, a reacting node can assume that a server that supports DOIC, but hasn't reported overload is not overloaded. It can make no such assumption about a server that doesn't support DOIC. If it does not know the difference between a non-overloaded server and a non-supporting server, it must assume all such servers are non-supporting. It ends up simply knowing that some servers _are_ overloaded, and some other servers _might_be_ overloaded.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 20:21:28 +0000

I agree with Ben here.
The mechanism is meant to work in mixed scenarios and it is relevant for the reacting node to know whether or not a server supports DOIC, since the reacting node should be able to mitigate this server overload as well when this server does not support DOIC.

In fact, we have already included this as a requirement  in our 3GPP TR:

6.3.3	Implicit Overload Indication
6.3.3.1	Introduction
IETF Draft draft-ietf-dime-overload-reqs-06 [4] talks about the use of implicit indications and the inadequacy of this approach for large, diverse networks.
However, a Diameter client may receive some overload indications as defined in Diameter base specification IETF RFC 6733 [2] and then it is recommended that the client uses them to mitigate overload situation. This may happen even if involved server and client support the new CN Overload mechanism under definition, but client handling of such indications is even more important when the new mechanism is not supported by either client or server.
At least the following indications may be considered:
-	DIAMETER_TOO_BUSY protocol error:
Diameter base specification IETF RFC 6733 [2] does not suggest that the receipt of a protocol error DIAMETER_TOO_BUSY response should affect future Diameter messages in any way, then it may be relevant for some applications to define the behavior that best mitigate the overload situation, taking into account application specifics, operator deployments.... For example, MME may implement a mitigation procedure based on the rate of received DIAMETER_TOO_BUSY protocol error from HSS.
-	Lack of response:
In case of overload the server may react dropping the requests without any Diameter error message being returned, what may imply retransmissions in the client side, negatively impacting overload. Therefore, for each application, it should be analyzed how to mitigate overload in this situation. For example, the client may consider avoiding retransmissions when a number of messages have not been answered.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: martes, 11 de febrero de 2014 16:55
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> 1) I want the reacting node to be able to learn if a (potentially) 
> reporting node supports DOIC, even when that node is not in overload. 
> I don't want to specify any particular behavior for that knowledge, 
> but I suspect implementations may want to treat DOIC compliant servers 
> in some way differently than they do non-DOIC servers. For example, I 
> might have a configured rate limit for non-DOIC peers, but use a 
> higher (or no) limit for peers that are known to support DOIC (and can 
> thus speak for themselves.) <Ulrich>sounds like a new requirement; 
> where does it come from? I would have thought that there is no need to 
> distinguish between

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Feb 2014 08:14:13 +0000

I understand your point but I'm not really convinced.

1. implicit indications (like answer message with result code TOO_BUSY and without piggybacked OLR or Lack of response) should be taken into account by reacting nodes independent from DOIC-support of the server.
2. How would the reacting node know whether the OC-Supported-Features AVP received in an answer indicates the features supported by the server (identified by the origin-host received in the answer) or the features supported by an agent on the path? 

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 9:21 PM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 12 Feb 2014 09:55:35 +0000

Ulrich,
Thanks for your response, see comments please

Best regards
/MCruz

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: miércoles, 12 de febrero de 2014 9:14
To: Maria Cruz Bartolome; [email-masked] list
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

1. implicit indications (like answer message with result code TOO_BUSY and without piggybacked OLR or Lack of response) should be taken into account by reacting nodes independent from DOIC-support of the server.
[MCruz] I agree. But one of the 3GPP requirements is to improve reacting node overload mitigation based on implicit indications (as described by TR), therefore any 3GPP application that will support new "Overload mitigation" feature (or whatever may be the name), shall improve its procedures with this objective. It is expected as well, that this new 3GPP "Overload mitigation" feature makes use of our DOIC, and then it is very beneficial that the reacting node could identify at any moment whether or not the reporting node supports DOIC, since procedures to be implemented could be potentially different.

2. How would the reacting node know whether the OC-Supported-Features AVP received in an answer indicates the features supported by the server (identified by the origin-host received in the answer) or the features supported by an agent on the path? 
[MCruz] Reacting node receives reporting node Supported-Features. Regardless the reporting node is either an agent or a server, in case the reacting node needs to treat "implicit indications" (like TOO_BUSY), expected reaction may depend on whether or not reporting node supports DOIC. This information is very beneficial to determine the most appropriate reaction.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 9:21 PM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Feb 2014 12:38:50 +0000

The reacting node (when receiving OC-Supported-Features AVP in an answer) knows that the corresponding request took a path towards the server on which there is a reporting node (which supports DOIC). It does not know whether this reporting node is the server or an agent and it does not know whether subsequent requests will take the same path or a different path on which there may be no reporting node. 
Consequently the presence of OC-Supported-Features AVP in an answer does not tell you anything usefull on which to base behaviour for subsequent requests targeted to the same server.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, February 12, 2014 10:56 AM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ulrich,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 9:21 PM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 13 Feb 2014 07:01:03 -0600

This could be addressed by adding the requirement that an
OC-Supported-Features AVP AVP that is inserted by an agent be marked as
such.

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 14 Feb 2014 12:17:39 +0000

Steve,
For my clarification:
Your proposal is to mark OC-Supported-Feature AVPs when inserted to answer messages by an agent?

If so, the reacting node can associate unmarked Supported-Features AVPs with the server (orig-host) and can discard marked Supported-Features AVPs.

Is that understanding correct?

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Thursday, February 13, 2014 2:01 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

This could be addressed by adding the requirement that an OC-Supported-Features AVP AVP that is inserted by an agent be marked as such.

Steve

-----Original Message-----

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

Ulrich,

Best regards

/MCruz

-----Original Message-----

To: Maria Cruz Bartolome; [email-masked]<mailto:[email-masked]> list

-----Original Message-----

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

I agree with Ben here.

6.3.3.1  Introduction

- Lack of response:

-----Original Message-----

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

On Feb 11, 2014, at 9:31 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]><mailto:[email-masked]> wrote:

distinguish between

a) DOIC not supported and therefore no traffic reduction requested,

and

b) DOIC supported, but not in overload and therefore no traffic

reduction requested</Ulrich>

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 14:46:45 +0000

Hi,

I think that two points are mixed:

1) For efficiency, a DOIC-enabled client should be able to mitigate (possible) overload situation even if explicit indication is not received from the network.
2) DOIC-enabled clients having a different behavior regarding support or not of DOIC by server.

if I agree with the first one, I disagree with the second one. The basic assumption is that a DOIC client will not throttle the traffic in absence of overload indication (explicit or implicit). And throttling will be performed as soon as an indication is received (explicit or implicit) if the client is designed for that (it supports DOIC or/and default behavior has been defined on reception of TOO_BUSY or non-response).

It is the only thing that matters today.

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : vendredi 14 février 2014 13:18
À : ext Steve Donovan; [email-masked]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Steve,
For my clarification:

Ulrich

Steve

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, February 12, 2014 10:56 AM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ulrich,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 9:21 PM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 14 Feb 2014 14:59:19 +0000

Did you mean "while I agree with the first one ..."?

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 3:47 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Hi,

Regards,

Lionel

Steve,
For my clarification:

Ulrich

Steve

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, February 12, 2014 10:56 AM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ulrich,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 9:21 PM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 15:17:14 +0000

Yes! :)

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : vendredi 14 février 2014 15:59
À : MORAND Lionel IMT/OLN; ext Steve Donovan; [email-masked]
Objet : RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 3:47 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Hi,

Regards,

Lionel

Steve,
For my clarification:

Ulrich

Steve

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, February 12, 2014 10:56 AM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ulrich,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 9:21 PM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 14 Feb 2014 15:23:46 +0000

I agree

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 4:17 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Yes! :)

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 3:47 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Subject: RE: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Hi,

Regards,

Lionel

Steve,
For my clarification:

Ulrich

Steve

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Wednesday, February 12, 2014 10:56 AM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ulrich,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 9:21 PM
To: [email-masked] list
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

I agree with Ben here.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 14 Feb 2014 15:59:34 -0600

> 2. How would the reacting node know whether the OC-Supported-Features AVP received in an answer indicates the features supported by the server (identified by the origin-host received in the answer)…

I think that, if an agent inserts OC-Supported-Features, that makes the agent the overload endpoint. If upstream servers that do not implement DOIC show implicit signs of overload, one hopes that agent will take action (whether that action means rejecting traffic, or originating an OLR back towards the client.)

So in this case, the reacting nodes peer "overload endpoint" is the agent. It knows the peer overload endpoint supports DOIC, and behaves accordingly.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 14 Feb 2014 16:06:42 -0600

> It is the only thing that matters today.

I disagree, for  reasons stated earlier. In summary, the requirement that reacting nodes be able to take different action depending on whether an opposite endpoint supports DOIC is a direct implication of requirements 16 and 18 of RFC 7068.

---

From: <[email-masked]>
Date: Sat, 15 Feb 2014 06:14:50 +0000

REQ 16: The solution is likely to be deployed incrementally.  The
           solution MUST support a mixed environment where some, but not
           all, nodes implement it.

   REQ 18: In a mixed environment of nodes that support the solution and
           nodes that do not, the solution MUST NOT preclude elements
           that support overload control from treating elements that do
           not support overload control in an equitable fashion relative
           to those that do.  Users and operators of nodes that do not
           support the solution MUST NOT unfairly benefit from the
           solution.  The solution specification SHOULD provide guidance
           to implementors for dealing with elements not supporting
           overload control.

Theses requirements are also fulfilled if servers or agents are able to handle clients that do not support DOIC and if client and agents are able to react to implicit overload indication received from the network.

In summary, I really don't see what is missing.

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : vendredi 14 février 2014 23:07
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : MORAND Lionel IMT/OLN; ext Steve Donovan; [email-masked]
Objet : Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages