Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt

Hi Laurent, comments inline:

On Dec 19, 2012, at 2:34 PM, "THIEBAUT, LAURENT (LAURENT)" <laurent.thiebaut@alcatel-lucent.com> wrote:

>  
>  
> Hello all
> Thanks Ben for the new version
> I think we are approaching towards the conclusion but would like to suggest following new requirements
>  

I hope you are right :-)

> REQ X:   A common default algorithm to react to an overload status SHOULD be defined in order to allow a basic inter-operable inter Service Provider overload mechanism.
>  

Do you consider an algorithm for inter-service-provider OC as necessarily different from a general algorithm? 

> REQ Y:   Even though there are Diameter Agents between 2 Diameter end-points (client/server) that support the (overload control) feature, there MUST be a way to report an *overload* status to the Diameter end-points (client/server) in order for Diameter end-points to be able to take proper (possibly non Diameter) actions.
>  

I assume from the elaboration below that this includes the case where the agents do not directly support OC?

>  
> So to us, the remaining work would be on Req2, Req X and Req Y.
>  
> It is recognized that Req Y is almost the same than Req 35 but with
> ·         a "MUST" instead of a "SHOULD"

I don't think I object to a MUST (pending conversation on the other parts)

> ·         the fact that even when the DA supports the mechanism the end point may need to know an *overload* status (this may be different for a *load* status)

Req 35 already says "overload and load information". Are you looking for more than that?

> ·         and (minor remark) the indication that the reaction to an overload status may imply possible non Diameter actions.
>  

Can you elaborate on what you mean by "non Diameter actions"? I think it likely that many overload conditions will require clients to take action in whatever application protocol they provide. Nothing really uses Diameter for it's on sake (we've got a fair amount of text on that in the introductory sections). But it seems to me the specifics of such actions belong to those protocols, not this one. Do you expect that the overload information would some how explicitly signal what non-Diameter actions a client might need to take?

> Best regards
> Laurent
> ALCATEL-LUCENT
>  
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoyé : mercredi 19 décembre 2012 09:48
> À : Ben Campbell
> Cc : dime@ietf.org
> Objet : Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt
>  
>  
> Hi Ben,
>  
> Thanks for the update. Now that the new revision is out
> I would encourage the WG to sort out the language in REQ 2
> asap. As long as it is in flux the document cannot proceed
> to WGLC.
>  
> - jouni
>  
>  
> On Dec 19, 2012, at 1:23 AM, Ben Campbell <ben@nostrum.com> wrote:
>  
> > Hi Everyone,
> >
> > We've submitted draft-ietf-dime-overload-reqs-02, based on the list discussions over the last few weeks. We believe this addresses all the substantive comments so far, except for the ongoing discussion on Req2 (concerning application independence and the impact on application specifications.) We've noted the open issue for Req 2 in the text.
> >
> > The new version is available at http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 . You can see a diff from version 01 at http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dime-overload-reqs-02.txt .
> >
> > Thanks!
> >
> > Ben.
> >
> > Begin forwarded message:
> >
> >> From: internet-drafts@ietf.org
> >> Subject: New Version Notification for draft-ietf-dime-overload-reqs-02.txt
> >> Date: December 18, 2012 5:19:27 PM CST
> >> To: ben@nostrum.com
> >> Cc: emcmurry@computer.org
> >>
> >>
> >> A new version of I-D, draft-ietf-dime-overload-reqs-02.txt
> >> has been successfully submitted by Ben Campbell and posted to the
> >> IETF repository.
> >>
> >> Filename:      draft-ietf-dime-overload-reqs
> >> Revision:      02
> >> Title:         Diameter Overload Control Requirements
> >> Creation date: 2012-12-17
> >> WG ID:         dime
> >> Number of pages: 27
> >> URL:             http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-02.txt
> >> Status:          http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs
> >> Htmlized:        http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02
> >> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-overload-reqs-02
> >>
> >> Abstract:
> >>  When a Diameter server or agent becomes overloaded, it needs to be
> >>  able to gracefully reduce its load, typically by informing clients to
> >>  reduce sending traffic for some period of time.  Otherwise, it must
> >>  continue to expend resources parsing and responding to Diameter
> >>  messages, possibly resulting in congestion collapse.  The existing
> >>  mechanisms provided by Diameter are not sufficient for this purpose.
> >>  This document describes the limitations of the existing mechanisms,
> >>  and provides requirements for new overload management mechanisms.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime
>  
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime