[Dime] Coming out of 100% reduction (was Re: WLGC #2 for draft-ietf-dime-ovli-06)

[Steve Donovan <[e-mail]>]

I'm ok with Maria Cruz's suggested change.

Steve

On 1/22/15 10:41 AM, Maria Cruz Bartolome wrote:
> Dear all,
>
> A) About 'M' bit:
>
> My understanding of RFC6733:
>
>        The 'M' bit, known as the Mandatory bit, indicates whether the
>        receiver of the AVP MUST parse and understand the semantics of the
>        AVP including its content.  The receiving entity MUST return an
>        appropriate error message if it receives an AVP that has the M-bit
>        set but does not understand it.  An exception applies when the AVP
>        is embedded within a Grouped AVP.  See Section 4.4 for details.
>
>         4.4:
>     Receivers of a Grouped AVP that
>     does not have the 'M' (mandatory) bit set and one or more of the
>     encapsulated AVPs within the group has the 'M' (mandatory) bit set
>     MAY simply be ignored if the Grouped AVP itself is unrecognized.  The
>     rule applies even if the encapsulated AVP with its 'M' (mandatory)
>     bit set is further encapsulated within other sub-groups, i.e., other
>     Grouped AVPs embedded within the Grouped AVP.
>
>
> If the Grouped AVP does not have the 'M' bit set, but one (or more) of its sub-AVPs do have it, then the grouped AVP may be ignored (instead of sending an error) if the Grouped AVP itself is "unrecognized"
> But what "unrecognized" mean in this context? In my opinion, the grouped AVP is not recognized as long as mandatory sub-AVPs are missed, this includes conditionally mandatory (up to negotiation) sub AVPs.
> Then I would proposed a variant to your proposal 2 below:
>
> 3) sub-AVPs of DOIC grouped AVPs MUST NOT  have the m-bit set unless the sub-avp is mandatory or conditionally mandatory (i.e. part of an extension explicitly negotiated in the feature vector).
>
>
> B) Going out of 100% reduction
>
> I think we should keep 5.2.2 as it is.
> But I think there is a bit of misalignment with 6.3. I will propose following rephrasing:
>
> Now: 5th paragraph:
>
>     If reacting node comes out of the 100 percent traffic reduction as a
>     result of the overload report timing out, the following procedures
>     are RECOMMENDED to be applied.  The reacting node sending the traffic
>     should be conservative and, for example, first send "probe" messages
>     to learn the overload condition of the overloaded node before
>     converging to any traffic amount/rate decided by the sender.  Similar
>     concerns apply in all cases when the overload report times out unless
>     the previous overload report stated 0 percent reduction.
>
> Proposed: 5th paragraph:
>
>     If reacting node comes out of the 100 percent traffic reduction as a
>     result of the overload report timing out,					<--
>                                                                  the reacting node sending the traffic	<--
>     SHOULD be conservative and, for example, first send "probe" messages	<--
>     to learn the overload condition of the overloaded node before
>     converging to any traffic amount/rate decided by the sender.  Similar
>     concerns apply in all cases when the overload report times out unless
>     the previous overload report stated 0 percent reduction.
>
>
> Best regards
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
> Sent: jueves, 22 de enero de 2015 15:38
> To: [e-mail]
> Subject: Re: [Dime] WLGC #2 for draft-ietf-dime-ovli-06
>
> All,
>
> We need to close these two issues to finish WGLC #2.
>
> Please review an let me know if the alternatives I have outlined below are acceptable.
>
> Thanks,
>
> Steve
>
> On 1/20/15 3:08 PM, Steve Donovan wrote:
>> On 1/20/15 1:20 PM, Ben Campbell wrote:
>>>> On Jan 20, 2015, at 12:42 PM, Steve Donovan
>>>> <[e-mail]> wrote:
>>>>
>>>> The following is the resolution of Ben's issues that were not
>>>> addressed directly in an email thread started by Ulrich.
>>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>>> -- 5.3, 4th paragraph:
>>>>>
>>>>> As I mentioned in previous discussion, after re-reading the related
>>>>> text in 6733, it's no longer clear to me this works like we thought
>>>>> it did. That is, I think any attempt to make sub-AVPs mandatory
>>>>> risks causing errors in the enclosing Diameter transaction. I don't
>>>>> know how to solve this, other just disallowing mandatory sub-AVPs.
>>>>> (Jouni previously convinced me 6733 treatment of the m-bit in
>>>>> sub-avps worked like we wanted--perhaps he can re-convince me :-)
>>>>>
>>>> SRD>Given that Jouni successfully convinced Ben about the 6733
>>>> treatment, I'm not planning to make any changes, as I'm assuming he
>>>> can be just as successful the second time.
>>> I think that's a bad assumption.
>>>
>>> We had previously assumed that if a node receives a grouped AVP
>>> (without the m-bit set) that includes an unrecognized sub-avp with
>>> the m-bit set, then the receiver could just ignore the entire grouped
>>> AVP, and otherwise process the transaction. But 6733 actually says
>>> the following:
>>>
>>> "Receivers of a Grouped AVP that
>>>      does not have the 'M' (mandatory) bit set and one or more of the
>>>      encapsulated AVPs within the group has the 'M' (mandatory) bit set
>>>      MAY simply be ignored if the Grouped AVP itself is unrecognized.
>>> The
>>>      rule applies even if the encapsulated AVP with its 'M' (mandatory)
>>>      bit set is further encapsulated within other sub-groups, i.e., other
>>>      Grouped AVPs embedded within the Grouped AVP."
>>>
>>> Note the "... if the Grouped AVP itself is unrecognized." clause.
>>>
>>> The case we have in mind is when you receive a _recognized_ grouped
>>> AVP (that is, you implement DOIC), but it includes an unrecognized
>>> sub-avp with the M-bit set. This is not covered by the exception.
>>> This would seem to indicate that the entire request must fail. I
>>> don't think that's what we want.
>> SRD> I see how it could be interpreted that way.
>>> At this point, I think we need to either say that sub-avps of DOIC
>>> grouped AVPs either 1) MUST NOT have the m-bit set, or 2) MUST NOT
>>> have the m-bit set unless the sub-avp is part of an extension
>>> explicitly negotiated in the feature vector.
>> SRD> I'm ok either way but prefer number 2).
>>>
>>>
>> [...]
>>>>> Paragraph 5:
>>>>>
>>>>> Is this redundant to the last paragraph of 5.2.2?
>>>>>
>>>> SRD> I don't see an issue.  One is general and the other specific to
>>>> the loss algorithm.  They don't conflict.
>>> The one in 5.2.2 is specific to situations where an OLR quenches all
>>> requests, and says MUST. So is this, and says RECOMMENDED (which
>>> means SHOULD in 2119).
>> SRD>Actually 5.2.2 isn't only about quenching.  It's also about the
>> reacting node having sent no traffic, because it had no traffic to
>> send, and now needs to send traffic soon after the OCS expires. The
>> reporting node might still be in an overload state but the reacting
>> node doesn't know until the first request is sent.
>>> If the idea is that the text in 6.3 is the recommended way to fulfill
>>> the MUST in 5.2.2, then that's okay I guess (although I would prefer
>>> one of the two to be non-normative.)
>> SRD> 6.3 deals specifically with quenching, thus is a little different
>> than 5.2.2, although there is overlap.
>>> Another approach would to leave this to 6.3, and add something to the
>>> effect that any new algorithm that can cause total quenching of
>>> requests must address how the reacting node restarts from that state.
>> SRD> I prefer to leave it as it currently is.
>>> [...]
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>