Subject: Re: [Dime] [doc-dt] Capability "Advertisement"

From: Steve Donovan <[email-masked]>
Date: Tue, 05 Nov 2013 03:52:41 -0800

Added DIME list.

Susan,

Once we have more than one algorithm we have to have the ability to for 
the server to send overload parameters for the algorithm type being used.

We have had a lot of conversation about the role of a server in 
selecting the algorithm to be used.  There was never agreement on the 
assertion that it is a burden for a server to deal with clients 
supporting different algorithms.   This is an inherent requirement that 
comes along with extensibility.

Steve

On 11/5/13, 3:14 AM, Shishufeng (Susan) wrote:
> Hi Lionel,
>
> I missed the discussion regarding the proposal to define an Overload Report (AVP) per algo and was actually surprised at it. I ever thought we had enough discussion regarding if the server cares about the algorithm implemented by the client. I didn't see the value to have overload report per algorithm. This just adds much more burden on the server to do the conversion per client/algorithm which actually can be done by the client itself.
>
> Best Regards,
> Susan
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 04, 2013 11:33 PM
> To: Shishufeng (Susan); Steve Donovan; [email-masked]
> Subject: RE: [doc-dt] Capability "Advertisement"
>
> Hi,
>
> As I have not received any answer, I try again:
>
> As said during the call, OK for OC-Feature AVP in answer, especially for enabling client to discover that a server DO NOT support any overload control mechanism.
> The existing text is clear on this point:
>
>     Once the endpoint that initiated the request message receives an
>     answer message from the remote endpoint, it can detect from the
>     received answer message whether the remote endpoint supports the
>     overload control solution and in a case it does, what features are
>     supported.
>
> About the proposal to define an Overload Report (AVP) per algo, is it something that you would agree on?
> Of course, extensibility of each grouped AVP would have to be ensured if any "missing/new" info needs to be added for an existing mechanism (e.g. add specific AVPs to support agent overload in the Loss algo).
> But, for any specific algo, it would maybe simpler to rely on its own grouped AVP to ease the answer processing. The AVP code can be directly associated to a unique algo instead of digging into an additional AVP (e.g. OC-Feature or single AVP inside a grouped AVP) to discover for which algo the Overload-Report is sent.
> Therefore, the aim of the current work in the DT draft would be to define the grouped AVP for reduction/loss and explain how new algo can be discovered. Does it make sense?
>
> Another point would be on the negotiation as soon as several algos are supported:
>
>     During the message exchange the overload control endpoints express
>     their common set of supported capabilities.  The endpoint sending a
>     request (the reacting node) includes the OC-Feature-Vector AVP with
>     those flags set that correspond what it supports.  The endpoint that
>     sends the answer (the reporting node) also includes the OC-Feature-
>     Vector AVP with flags set to describe ^^the capabilities it both
>     supports and agrees with the request sender^^ (e.g., based on the local
>     policy and/or configuration).  The answer sending endpoint (the
>     reporting node) does not need to advertise those capabilities it is
>     not going to use with the request sending endpoint (the reacting
>     node).
>
> I think it is not so true and/or incomplete. Both endpoints will support the default algo (0) and a server cannot say "I will not use the default algo with you" because it could mean the same as "I'm not supporting the default", that is a non-sense by definition of a default.
>
> In any case, what is the harm for a server to advertize in the response all the algos that it supports if when sending an overload report the use of a specific grouped AVP will let the client know the algo to use according to this report?
> If both endpoints advertize all the supported capabilities each time, I think it would ease the use of the OC-Feature.
> What do you think?
>
> Lionel
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Shishufeng (Susan)
> Envoyé : lundi 4 novembre 2013 12:19
> À : Steve Donovan; [email-masked]
> Objet : Re: [doc-dt] Capability "Advertisement"
>
> Hi Steve and all,
>
> I agree to have the capability advertisement mechanism. For the base version, it should be a way for the client and server, especially the server knows if the another node supports DOC or not, e.g. the server can decide if it can send overload reporting information to the client to request traffic reduction. To the client, what I can imagine is, if the client knows the server does not support DOC and is unable to provide overload information of the server to the client, the client has to apply its own mechanism as currently to drop messages e.g. when the messages which are not responded by the server reaches the configured window. While all of these capabilities so far are not related the algorithms implemented at the client.
>
> Best Regards,
> Susan
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Donovan
> Sent: Thursday, October 31, 2013 9:23 PM
> To: [email-masked]
> Subject: [doc-dt] Capability "Advertisement"
>
> All,
>
> Breaking the question of negotiation down in to its parts, I believe we
> have consensus on the need to support extensibility.  Does anyone
> disagree with this?
>
> The next question is then whether we agree that DOIC End-Points (to use
> the term in the draft) must advertise that DOIC capabilities it
> supports.  There is only one capability in the base draft, but the
> expectation is that more capabilities will be defined.
>
> Do we have agreement on the need to support capabilities advertisement?
>
> The next question will be what the receiving DOIC end-point does with
> the advertisement but I think there is value in making sure we agree
> that advertisement is needed before continuing that discussion.
>
> Regards,
>
> Steve
> _______________________________________________
> doc-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doc-dt
> _______________________________________________
> doc-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doc-dt
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> doc-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doc-dt
>