Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt

[Steve Donovan <[e-mail]>]

Ulrich,

Thanks for the comments.  Please see my responses inline.

Regards,

Steve
On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Hi Steve,
> here are my comments.
> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept.
SRD> We have never had an agreement on end-to-end versus hop-by-hop and 
I believe that we will end up with a hybrid of the two.  We have open 
issues on agent behavior that Ben and I are attempting to address with 
the agent cases draft.

SRD> That said, this type of restructuring of the document is likely to 
put agreed to behavior in a new light.  If there are cases where I have 
implied changes to agreed to normative behavior, or if the informative 
text is not accurate, then these things need to be corrected.
>
> 1. clause 2.3, second paragraph:
> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node."
SRD> You mean clause 3.2.  I agree with the change.
>
> 2. clause 2.3, 3rd paragraph, 1st sentence:
> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP.
SRD> Agreed.
>
> 3. clause 3.3, 7th paragraph:
> Should read "The reporting node only includes an indication of support for one overload abatement algorithm.  This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested."
SRD. OK.
>
> 4. clause 3.3, 10th paragraph:
> The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node).
> The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)".
> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently.
SRD> I don't know what you mean when you say an agent is transparent.  
Agents must take an active role in even the most basic case for overload 
handling to work, so they cannot be transparent.
>
> 5. clause 3.3, last paragraph:
> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always).
SRD> What two associations?  Is there one association (end-to-end) or is 
the an association on both sides of the agent (hop-by-hop)?  Or is there 
an association that involves three entities, the reporting node, an 
agent reacting node for realm-routed requests and a transaction-client 
reporting node for handling host-routed requests?
>
> 6. clause 3.4, 2nd paragraph:
> Should read: "The OC-OLR AVP is referred to as an overload report.  The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs."
SRD> The sequence number is being used as an overload report ID. I can 
make the change but I don't see it as necessary.
>
> 7. clause 3.4, 4th paragraph, 2nd sentence:
> I cannot understand this sentence. Probably only simple typos but I don't know.
SRD> Yes, a typo (this instead of the) and awkward wording.  How about 
"This applies to requests that contain the Destination-Host AVP with a 
DiameterIdentity that matches the overload report.
>
> 8. clause 3.4, 4th paragraph last 2 sentences:
> I don't understand and probably do not agree.
SRD> See above.
>
> 9. clause 3.5, 3rd paragraph, last word:
> Should read "communicated"
SRD> Agreed.
>
> 10. clause 3.5, 4th paragraph, 1st sentence:
> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes."
SRD> Who else would reports be sent to?
>
> 11. clause 4.1, 3rd paragraph, last 4 words:
> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support.
SRD> I disagree.
>
> 12. clause 4.1, 4th paragraph, 2nd sentence:
> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP."
SRD> That is what it already says.
>
> 13. clause 4.1, last sentence:
> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests.
SRD> This is a topic on agent behavior that is addressed in the agent 
cases draft.  I'll leave the discussion for what the wording should be 
to the discussion on that draft.
>
> 14. clause 4.1.2, 2nd paragraph:
> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node.  The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction."
SRD> It would be easier if you didn't make it difficult to understand 
the change you are proposing.  I think you are proposing changing 
node(s) to node.  I don't agree but that will be addressed as part of 
the agent cases discussion.
>    
> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word:
> Should read: "message's"
SRD> I'm assuming you mean section 4.1.2.  I agree to the change.
>
> 16. clause 4.1, 6th paragraph:
> This should be left to the (future) specification that introduces other DOIC features.
>
> 17. clause 4.1, 7th paragraph, last 6 words:
> should be based on requiements set by the (future) specification that introduces other DOIC features
SRD> Again, clause 4.1.2 -- I don't understand the issue when these two 
paragraphs are taken together.
>
> 18. clause 4.1, 8th paragraph, last sentence:
> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction."
SRD> I think you mean clause 4.1.2.  I don't see the need for the change.
>
> 19. clause 4.1, last sentence:
> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request.
SRD> What is the difference between modify and replace?  I am ok with 
removing this statement until we have the agent behavior discussion.  I 
thought I had taken the agent specific statements out of this version.
>
> 20. clause 5.2, 1st sentence:
> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction."
SRD> Agreed.
>
> 21. clause 5.2, last sentence:
> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed."
SRD> Yes, bad wording.  The note will be removed, bad wording and all, 
once there is a discussion on if this is redundant.
>
> 22. clause 5.4, 6th paragraph:
> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node."
SRD Agreed, this is more clear.
>
>
> Best regards
> Ulrich
>
>
>
> -----Original Message-----
> From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
> Sent: Saturday, July 05, 2014 9:42 PM
> To: [e-mail]
> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt
>
> All,
>
> This version of the DOIC draft is a restructuring of previously agreed
> to content.
>
> The master plan for the restructuring is in Appendix C.  This outlines
> where material from -02 was moved in -03.
>
> For those interested, the work was done in steps, with a snapshot for
> each step available here:
>
> https://github.com/jounikor/draft-docdt-dime-ovli
>
> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt
>
> where nn indicates the subversion and "text" indicates the focus for
> that subversion.
>
> The next step will be to resolve open issues already identified and
> those yet those yet to be identified.
>
> Regards,
>
> Steve
>
>
> On 7/3/14, 2:31 PM, [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>    This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.
>>
>>           Title           : Diameter Overload Indication Conveyance
>>           Authors         : Jouni Korhonen
>>                             Steve Donovan
>>                             Ben Campbell
>>                             Lionel Morand
>> 	Filename        : draft-ietf-dime-ovli-03.txt
>> 	Pages           : 48
>> 	Date            : 2014-07-03
>>
>> Abstract:
>>      This specification documents a Diameter Overload Control (DOC) base
>>      solution and the dissemination of the overload report information.
>>
>> Requirements
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>