Re: [Dime] OVLI: comments to 4.3

Dear all,

See my comments below.
Best regards
MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: lunes, 09 de diciembre de 2013 23:25
To: Nirav Salot (nsalot)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.3

On Dec 9, 2013, at 6:43 AM, Nirav Salot (nsalot) <nsalot@cisco.com> wrote:

> Ulrich,
> 
>> it is also an important part that the reacting node calculates the expiry time of an OLR based on the included timestamp and duration and not based on the reception time and the included duration.
> I do not agree that this is important.

> I do not see any issue if the reacting node starts the timer equal to Validity-Period on reception of the message containing a fresh OC-OLR.
> I agree that this means each reacting node will run this timer for different duration since each of them will start the timer of the same value but starting from the time when they received OC-OLR. But this is not an issue since Validity-Period is anyway a guestimate and it would provide a natural ramp up effect (to avoid message storm at the reporting node) if each of the reacting node stops the throttling at different time.
> 

[Ben] Nirav and I agree on something for a change :-) The validity period is from the time you first get the OLR. It's not based on a timestamp in the message. The in-transit times for an OLR are not going to be so long, and the need for precision not so high, to justify the need for a time reference in the OLR.

[MCruz] I agree with Ben and Nirav, I think it is enough to start the validity period when the OLR is received by reacting node.

>> It is much simpler for reporting nodes to include a pre-calculated OLR into the answer rather than  to adjust the validity-duration in the OLR in dependency of the time when the OLR is included into the answer.
> I agree. The reporting node should not be required to adjust Validity-Period while sending OC-OLR to different reacting nodes. I do not see any need to do so based on my explanation above.
> 

[Ben] This would only be an issue if we expect an overloaded node to keep the same overload state for relatively long periods of time. The nature of overload is such that I do not expect that to be true.
However, one point we need to be clear on is that receipt of a new copy of the same OLR does not restart the timer.

[MCruz] My understanding is that validity-period should be adjusted by reporting node depending on their expectations on traffic reduction by one client. Therefore, it should be updated towards _each_ client, based on reporting node expectations on _each_ client traffic reduction. I understand it does not mean (necessarily) that validity period has to be updated each time a message is sent, but it will depend on each overload situation and per client.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime