Re: [Dime] [Gen-art] Gen-ART review of draft-ietf-dime-overload-reqs-12

[Jari Arkko <[e-mail]>]

Indeed, thank you.

Jari

On Sep 20, 2013, at 12:40 PM, Jouni Korhonen <[e-mail]> wrote:

> 
> Thanks David.
> 
> - JOuni
> 
> 
> On Sep 20, 2013, at 2:57 AM, "Black, David" <[e-mail]> wrote:
> 
>> And the -12 version is likewise ready for publication as an Informational RFC.
>> 
>> Thanks,
>> --David
>> 
>>> -----Original Message-----
>>> From: Black, David
>>> Sent: Tuesday, August 27, 2013 12:41 PM
>>> To: Ben Campbell
>>> Cc: Eric McMurry; General Area Review Team ([e-mail]); [e-mail];
>>> [e-mail]; [e-mail]; Black, David
>>> Subject: Gen-ART review of draft-ietf-dime-overload-reqs-11
>>> 
>>> The -11 version of this draft addresses all of the nits and editorial comments
>>> noted in the Gen-ART review of the -10 version.  It's ready for publication as
>>> an Informational RFC.
>>> 
>>> Thanks,
>>> --David
>>> 
>>>> -----Original Message-----
>>>> From: Ben Campbell [mailto:[e-mail]]
>>>> Sent: Thursday, August 22, 2013 4:50 PM
>>>> To: Black, David
>>>> Cc: Eric McMurry; General Area Review Team ([e-mail]);
>>> [e-mail];
>>>> [e-mail]; [e-mail]
>>>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
>>>> 
>>>> Hi David,
>>>> 
>>>> We agree on all your points, and will make the updates in the next version,
>>>> pending shepherd instructions.
>>>> 
>>>> Thanks!
>>>> 
>>>> Ben.
>>>> 
>>>> On Aug 22, 2013, at 2:50 PM, "Black, David" <[e-mail]> wrote:
>>>> 
>>>>> Hi Eric,
>>>>> 
>>>>> This looks good - comments follow ...
>>>>> 
>>>>>>> a) I assume that overload control development work will derive more
>>>> specific
>>>>>>> security requirements - e.g., as REQ 27 is stated at a rather high
>>> level.
>>>>>>> The discussion in security considerations section seems reasonable.
>>>>>> 
>>>>>> We agree with this.  The thinking here was that we didn't want to specify
>>> this
>>>>>> in a way that would be specific to a particular type of mechanism.  It
>>> might
>>>>>> not hurt to state that assumption, either as a note on Req 27 or in the
>>> sec
>>>>>> considerations.
>>>>> 
>>>>> That would be good to add as a note on REQ 27.
>>>>> 
>>>>>> The intent was very much as you say, where requirements on individual
>>> node
>>>>>> capabilities are hoped to result in better overall system behaviors.
>>> There are
>>>>>> also some requirements that are stated more at the system level (e.g. 7
>>> and
>>>>>> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
>>>>>> insufficient server capacity at a cluster of servers behind a Diameter
>>> agent
>>>>>> can be treated as if the agent itself was overloaded.
>>>>>> 
>>>>>> On the other hand, any mechanism we design will have to focus on actions
>>> of
>>>>>> individual nodes, so the numbered requirements tend to focus on that. I'm
>>> not
>>>>>> sure where to change the balance here--do you have specific suggestions?
>>>>> 
>>>>> I noted this as editorial rather than a minor issue, as I was mostly
>>> concerned
>>>>> that the actual design work will be informed by a sufficient architectural
>>> "clue"
>>>>> that the goal is "better overall system behaviors", which your response
>>> indicates
>>>>> will definitely be the case ;-).
>>>>> 
>>>>> Rather than edit individual requirements, how about adding the following
>>> sentence
>>>>> immediately following the introductory sentence in Section 7?:
>>>>> 
>>>>> 	These requirements are stated primarily in terms of individual node
>>>>> 	behavior to inform the design of the improved mechanism;
>>>>> 	that design effort should keep in mind that the overall goal is
>>>>> 	improved overall system behavior across all the nodes involved,
>>>>> 	not just improved behavior from specific individual nodes.
>>>>> 
>>>>>>> This inadequacy may, in turn, contribute to broader congestion collapse
>>>>>>> 
>>>>>>> "collapse" is not the right word here - I suggest "issues", "impacts",
>>>>>>> "effects" or "problems".
>>>>>> 
>>>>>> We are fine with any of those alternatives.  How about impacts.
>>>>> 
>>>>> That's fine.  FWIW, "congestion collapse" has a specific (rather severe)
>>>>> meaning over in the Transport Area, and that meaning was not intended
>>> here.
>>>>> 
>>>>>> 23.843 is the least stable reference.  I don't have any issue with
>>> pointing
>>>>>> that out.  The part of it we are referencing is historical front matter
>>>>>> though.
>>>>> 
>>>>> I'd note the reference as work in progress, and put the statement about
>>> stable
>>>>> front matter (historical is a bad work to use here) in the body of the
>>> draft
>>>>> that cites the reference.
>>>>> 
>>>>>> I tried the web and downloaded versions of 2.12.17 and was not able to
>>> get the
>>>>>> warnings you saw (about the references).  What did it say?
>>>>> 
>>>>> Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits
>>> confusion
>>>>> manifested right at the top of the output, where everyone ignores it ...
>>>>> 
>>>>> Attempted to download rfc272 state...
>>>>> Failure fetching the file, proceeding without it.
>>>>> 
>>>>> You didn't reference RFC 272, so that output's apparently courtesy of
>>> idnits
>>>>> misinterpreting this reference:
>>>>> 
>>>>> 1195	   [TS29.272]
>>>>> 1196	              3GPP, "Evolved Packet System (EPS); Mobility
>>> Management
>>>>> 1197	              Entity (MME) and Serving GPRS Support Node (SGSN)
>>> related
>>>>> 1198	              interfaces based on Diameter protocol", TS 29.272
>>> 11.4.0,
>>>>> 1199	              September 2012.
>>>>> 
>>>>> I was amused :-).
>>>>> 
>>>>> Thanks,
>>>>> --David
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Eric McMurry [mailto:[e-mail]]
>>>>>> Sent: Thursday, August 22, 2013 3:06 PM
>>>>>> To: Black, David
>>>>>> Cc: [e-mail]; General Area Review Team ([e-mail]);
>>>>>> [e-mail]; [e-mail]; [e-mail]
>>>>>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
>>>>>> 
>>>>>> Hi David,
>>>>>> 
>>>>>> Thank you for the review.  Your time and comments are appreciated!
>>>>>> 
>>>>>> comments/questions inline.
>>>>>> 
>>>>>> 
>>>>>> Eric
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Aug 17, 2013, at 9:18 , "Black, David" <[e-mail]> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>>>>>> Gen-ART, please see the FAQ at
>>>>>>> 
>>>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>>>> 
>>>>>>> Please resolve these comments along with any other Last Call comments
>>>>>>> you may receive.
>>>>>>> 
>>>>>>> Document: draft-ietf-dime-overload-reqs-10
>>>>>>> Reviewer: David L. Black
>>>>>>> Review Date: August 17, 2013
>>>>>>> IETF LC End Date: August 16, 2013
>>>>>>> IESG Telechat date: (if known)
>>>>>>> 
>>>>>>> Summary:
>>>>>>> This draft is basically ready for publication, but has nits that should
>>> be
>>>>>>> fixed before publication.
>>>>>>> 
>>>>>>> This draft describes scenarios in which Diameter overload can occur and
>>>> provides
>>>>>>> requirements for development of new overload control functionality in
>>>> Diameter.
>>>>>>> It is well written, and the inclusion of scenarios in which overload can
>>>> occur,
>>>>>>> both in terms of the relationships among types of Diameter nodes and
>>>> actual mobile
>>>>>>> network experience is very helpful.
>>>>>>> 
>>>>>>> I apologize for this review being a day late, as I've been on vacation
>>> for
>>>> most
>>>>>>> of this draft's IETF Last Call period.
>>>>>>> 
>>>>>>> Major issues: (none)
>>>>>>> 
>>>>>>> Minor issues: (none)
>>>>>>> 
>>>>>>> Nits/editorial comments:
>>>>>>> 
>>>>>>> The following two comments could be minor issues, but I'm going to treat
>>>> them
>>>>>>> as editorial, as I expect that they will be addressed in development of
>>>> the
>>>>>>> actual overload functionality:
>>>>>>> 
>>>>>>> a) I assume that overload control development work will derive more
>>>> specific
>>>>>>> security requirements - e.g., as REQ 27 is stated at a rather high
>>> level.
>>>>>>> The discussion in security considerations section seems reasonable.
>>>>>> 
>>>>>> We agree with this.  The thinking here was that we didn't want to specify
>>>> this
>>>>>> in a way that would be specific to a particular type of mechanism.  It
>>>> might
>>>>>> not hurt to state that assumption, either as a note on Req 27 or in the
>>> sec
>>>>>> considerations.
>>>>>> 
>>>>>>> 
>>>>>>> b) The draft, and especially its requirements in Section 7 are strongly
>>>>>>> focused on individual Diameter node overload.  That's necessary, but
>>>> overload
>>>>>>> conditions can be broader, affecting an entire service or application,
>>> or
>>>>>>> multiple instances of either/both, even if not every individual Diameter
>>>> node
>>>>>>> involved is overloaded.  A number of the requirements, starting with REQ
>>>> 22
>>>>>>> could be generalized to cover broader overload conditions.
>>>>>>> 
>>>>>>> This (b) has implications for other requirements, e.g., REQ 13 should
>>> also
>>>> be
>>>>>>> generalized beyond a single node to avoid increased traffic in an
>>> overload
>>>>>>> situation, even from a node that is not overloaded by itself.  There are
>>>> limits
>>>>>>> on what is reasonable here, as the desired overload functionality is
>>>> TCP/SCTP-
>>>>>>> like reaction to congestion where individual actions taken by nodes
>>> based
>>>> on
>>>>>>> the information they have (which is not the complete state of the
>>> network)
>>>>>>> results in an overall reduction of load.
>>>>>> 
>>>>>> The intent was very much as you say, where requirements on individual
>>> node
>>>>>> capabilities are hoped to result in better overall system behaviors.
>>> There
>>>> are
>>>>>> also some requirements that are stated more at the system level (e.g. 7
>>> and
>>>>>> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
>>>>>> insufficient server capacity at a cluster of servers behind a Diameter
>>>> agent
>>>>>> can be treated as if the agent itself was overloaded.
>>>>>> 
>>>>>> On the other hand, any mechanism we design will have to focus on actions
>>> of
>>>>>> individual nodes, so the numbered requirements tend to focus on that. I'm
>>>> not
>>>>>> sure where to change the balance here--do you have specific suggestions?
>>>>>> 
>>>>>>> 
>>>>>>> Section 1.2, 2nd paragraph:
>>>>>>> 
>>>>>>> as network congestion, network congestion can reduce a Diameter nodes
>>>>>>> 
>>>>>>> "nodes" -> "node's"
>>>>>> 
>>>>>> good catch.
>>>>>> 
>>>>>>> 
>>>>>>> Section 5, 1st paragraph:
>>>>>>> 
>>>>>>> This inadequacy may, in turn, contribute to broader congestion collapse
>>>>>>> 
>>>>>>> "collapse" is not the right word here - I suggest "issues", "impacts",
>>>>>>> "effects" or "problems".
>>>>>> 
>>>>>> We are fine with any of those alternatives.  How about impacts.
>>>>>> 
>>>>>>> 
>>>>>>> Section 7
>>>>>>> 
>>>>>>> The long enumerated list of requirements is not an easy read.  It would
>>> be
>>>>>>> better if these could somehow be grouped by functional category, e.g.,
>>>>>>> security, transport interactions, operational/administrative, etc.
>>>>>> 
>>>>>> agree.  It is actually in sections in the XML (denoted by comments), we
>>>> just
>>>>>> did not promote those to visible sections in the txt.  I recall there
>>> being
>>>>>> some issue with xml2rfc and numbering, but now that the numbers are set,
>>>> this
>>>>>> would not be hard to do.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> idnits 2.12.17 noticed the non-standard RFC 2119 boilerplate - this is
>>>> fine,
>>>>>>> as the boilerplate has been appropriately modified for this draft that
>>>>>>> expresses requirements (as opposed to a draft that specifies a
>>> protocol).
>>>>>>> 
>>>>>>> idnits 2.12.17 got confused by the 3GPP and GSMA Informative References.
>>>>>>> I assume that they're all sufficiently stable to be informative
>>>> references.
>>>>>>> However, [TR23.843] is a work in progress, and should be noted as such
>>> in
>>>>>>> its reference - is this needed for any of the other 3GPP or GSMA
>>>> references?
>>>>>> 
>>>>>> 23.843 is the least stable reference.  I don't have any issue with
>>> pointing
>>>>>> that out.  The part of it we are referencing is historical front matter
>>>>>> though.
>>>>>> 
>>>>>> 
>>>>>> I tried the web and downloaded versions of 2.12.17 and was not able to
>>> get
>>>> the
>>>>>> warnings you saw (about the references).  What did it say?
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> --David
>>>>>>> ----------------------------------------------------
>>>>>>> David L. Black, Distinguished Engineer
>>>>>>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>>>>>>> [phone]             FAX: [phone]
>>>>>>> [e-mail]        Mobile: [phone]
>>>>>>> ----------------------------------------------------
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art