[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf
Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-12
From: Jouni Korhonen <jouni.nospam () gmail ! com>
Date: 2013-09-20 9:40:19
Message-ID: 86EF9C2C-9FDC-4046-B7D1-323C0122C0C2 () gmail ! com
[Download RAW message or body]
Thanks David.
- JOuni
On Sep 20, 2013, at 2:57 AM, "Black, David" <david.black@emc.com> 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 (gen-art@ietf.org); ietf@ietf.org;
>> dime@ietf.org; bclaise@cisco.com; 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:ben@nostrum.com]
>>> Sent: Thursday, August 22, 2013 4:50 PM
>>> To: Black, David
>>> Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org);
>> ietf@ietf.org;
>>> dime@ietf.org; bclaise@cisco.com
>>> 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" <david.black@emc.com> 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:emcmurry@computer.org]
>>>>> Sent: Thursday, August 22, 2013 3:06 PM
>>>>> To: Black, David
>>>>> Cc: ben@nostrum.com; General Area Review Team (gen-art@ietf.org);
>>>>> ietf@ietf.org; dime@ietf.org; bclaise@cisco.com
>>>>> 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" <david.black@emc.com> 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
>>>>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786
>>>>>> david.black@emc.com Mobile: +1 (978) 394-7754
>>>>>> ----------------------------------------------------
>>>>>>
>>>>>
>>>>
>>>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic