Re: [Dime] Ongoing Throttling Information in request messages

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

-----Original Message-----
From: ext Ben Campbell [mailto:[e-mail]] 
Sent: Wednesday, November 27, 2013 9:39 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Nirav Salot (nsalot); [e-mail]
Subject: Re: [Dime] Ongoing Throttling Information in request messages


On Nov 27, 2013, at 10:48 AM, Wiehe, Ulrich (NSN - DE/Munich) <[e-mail]> wrote:

> Ben,
> 
> Please see inline.
> 
> Ulrich
> 
> -----Original Message-----
> From: ext Ben Campbell [mailto:[e-mail]] 
> Sent: Wednesday, November 27, 2013 4:30 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext Nirav Salot (nsalot); [e-mail]
> Subject: Re: [Dime] Ongoing Throttling Information in request messages
> 
> 
> On Nov 27, 2013, at 5:21 AM, Wiehe, Ulrich (NSN - DE/Munich) <[e-mail]> wrote:
> 
>> Ben,
>> 
>> thank you for not objecting to marking requests that survived a throttling.
> 
> To be clear, by "not objecting" I mean that I think it might be a worthwhile extension to pursue, but I'm not convinced it needs to go in the base spec.
> 
>> From here it is only a small step to additionally indicate which type of throttling (10% or 80% or.... identified by timestamp) the request survived.
> 
> I'm not sure what the purpose of that would be.
> [Wiehe, Ulrich (NSN - DE/Munich)] This is to allow the reporting node to detect whether the reacting node is already doing the correct throttling or whether it is still doing a throttling based on stale information and therefore needs to be updated with the latest OLR.
> 

This seems like premature optimization. 

[Wiehe, Ulrich (NSN - DE/Munich)] no, unless we say "doing the wrong throttling is good - doing the correct throttling is an optimization"
It adds quite a bit of complexity, and I don't think the returns are going to be worth it. 
[Wiehe, Ulrich (NSN - DE/Munich)] I do not agree


>> 
>> Open issue is to assess whether
>> 
>> a) executing some logic (timestamp check) always + sending OLR only in the very few cases where it is needed
>> is more expensive (in terms or resource consumption contributing to overload) than
>> b) sending OLR always
> 
> Agreed, but with the caveat that we still have c) reporting node resends when it wants to.
> [Wiehe, Ulrich (NSN - DE/Munich)] no. It's either "send OLR when needed and when not needed" (i.e. always see b)) or "send OLR when needed and don't send OLR when not needed (see a)). "do what you want" would allow not sending OLR although needed.

By "do what you want" I mean that you follow local policy to determine when it's needed. We don't need the protocol to normatively define that.

[Wiehe, Ulrich (NSN - DE/Munich)] how would the local policy be able to determine the right thing to do?

> 
>> 
>> One approach could be to 
>> - mandate sending of Ongoing-Throttling-Information(TimeStamp) in request messages by acting nodes while performing throttling
>> - reporting nodes that are in overload may either do a) or b) whatever is regarded less resource consuming by the implementation
>> - reporting nodes that are not (no longer) overloaded must do a)
> 
> Why the last point? I'd leave it as a MAY for both cases.
> [Wiehe, Ulrich (NSN - DE/Munich)] because non-overloaded reporting nodes do not do b)

Your last bullet said "reporting nodes that are not (no longer) overloaded must do a)" That's not a "may".
[Wiehe, Ulrich (NSN - DE/Munich)] I agree, it's not a "may", it is a "must".

>