Subject: Re: [Dime] DOIC WGLC: duration unit

From: Steve Donovan <[email-masked]>
Date: Wed, 07 Jan 2015 09:41:39 -0600

I am making these changes in DOIC-06.

We will need another WGLC.  If there are objections to this it can be 
addressed during that WGLC.

Steve

On 12/29/14 10:40 AM, Steve Donovan wrote:
> It appears that we are moving toward consensus to move back to 
> seconds.  If we do then I agree that a 24 hour maximum is reasonable.
>
> Does anyone object to moving back to seconds with a 24 hour maximum?
>
> Regards,
>
> Steve
>
> On 12/22/14 3:59 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>> Dear all
>>
>> I am also ,in favor  to take the second as unit (according to Ben 's 
>> arguments), and also to have a upper limit. The limit that Ben gives 
>> is about 50 days. Is 24 hours too short?
>>
>> Best regards
>>
>> JJacques
>>
>> -----Message d'origine-----
>> De : DiME [mailto:[email-masked]] De la part de Ben Campbell
>> Envoyé : vendredi 19 décembre 2014 00:47
>> À : Wiehe, Ulrich (NSN - DE/Munich)
>> Cc : [email-masked]
>> Objet : Re: [Dime] DOIC WGLC: duration unit
>>
>> Hi Ulrich,
>>
>> You bring up a good point that we need to document the limits, or at 
>> least describe the implications of choosing to long or short of a 
>> duration either way. I suspect 1s is still too short for most 
>> situations, and  ( 2^32 - 1 / 1000 )s is probably still too long.
>>
>> (Don't get me wrong; I still think millisecond resolution for this is 
>> silly.)
>>
>> Thanks!
>>
>> Ben.
>>
>>> On Dec 18, 2014, at 11:11 AM, Wiehe, Ulrich (NSN - DE/Munich) 
>>> <[email-masked]> wrote:
>>>
>>> Ben,
>>>
>>> my inclination is to change back to seconds. However, seconds allow 
>>> a maximum value that is 1000 times higher and may be regarded 
>>> unreasonably high. In a previous version of the draft we had an 
>>> upper limit, and maybe when going back to seconds we should 
>>> re-introduce an upper limit so that the protocol does not allow 
>>> unreasonably long durations.
>>>
>>> Ulrich
>>>
>>>
>>> -----Original Message-----
>>> From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
>>> Sent: Thursday, December 18, 2014 12:08 AM
>>> To: Jouni Korhonen
>>> Cc: [email-masked]
>>> Subject: Re: [Dime] DOIC WGLC: duration unit
>>>
>>>
>>>> On Dec 17, 2014, at 5:01 PM, Jouni Korhonen 
>>>> <[email-masked]> wrote:
>>>>
>>>> [snip]
>>>>
>>>>>> I'll step out of the argument and let someone else be champion 
>>>>>> for millisecond granularity.
>>>>> Any other takers? Are there real use cases for sub-second precision?
>>>> I do not really care. We changed that from seconds to milliseconds 
>>>> for some reason.. but no not see a reason to change it back either.
>>> I'd argue that we should make it the "right thing", regardless of 
>>> whether we changed it before. (Although remembering why might go far 
>>> to answering my last question below.)
>>>
>>> I've describe why I think it is false precision, and can become 
>>> harmful. To rephrase it, choosing too small of durations will cause 
>>> harm by forcing rapid OLR updates (as in many per second.) These 
>>> updates cause work for both reporting nodes and reacting nodes.
>>>
>>> We could offer guidance of how to avoid that harm. Or we could 
>>> choose a resolution that makes it harder to cause such harm in the 
>>> first place. I think good protocol design favors the later.
>>>
>>> Do you disagree with the potential for harm? Or do you see some use 
>>> case for sub-second precision that I've missed?
>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Jan 2015 13:57:28 -0600

Oops, I missed your original call for objections in the post-holiday deluge. For the record, I agree with both the unit and the limit.

> On Jan 7, 2015, at 9:41 AM, Steve Donovan <[email-masked]> wrote:
> 
> We will need another WGLC.  If there are objections to this it can be addressed during that WGLC.
> 
> Steve
> 
>> It appears that we are moving toward consensus to move back to seconds.  If we do then I agree that a 24 hour maximum is reasonable.
>> 
>>> I am also ,in favor  to take the second as unit (according to Ben 's arguments), and also to have a upper limit. The limit that Ben gives is about 50 days. Is 24 hours too short?
>>> 
>>> Best regards
>>> 
>>> JJacques
>>> 
>>> You bring up a good point that we need to document the limits, or at least describe the implications of choosing to long or short of a duration either way. I suspect 1s is still too short for most situations, and  ( 2^32 - 1 / 1000 )s is probably still too long.
>>> 
>>> (Don't get me wrong; I still think millisecond resolution for this is silly.)
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> 
>>>> On Dec 18, 2014, at 11:11 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:
>>>> 
>>>> Ben,
>>>> 
>>>> my inclination is to change back to seconds. However, seconds allow a maximum value that is 1000 times higher and may be regarded unreasonably high. In a previous version of the draft we had an upper limit, and maybe when going back to seconds we should re-introduce an upper limit so that the protocol does not allow unreasonably long durations.
>>>> 
>>>> Ulrich
>>>> 
>>>> 
>>>>> On Dec 17, 2014, at 5:01 PM, Jouni Korhonen <[email-masked]> wrote:
>>>>> 
>>>>> [snip]
>>>>> 
>>>>>>> I'll step out of the argument and let someone else be champion for millisecond granularity.
>>>>> I do not really care. We changed that from seconds to milliseconds for some reason.. but no not see a reason to change it back either.
>>>> I'd argue that we should make it the "right thing", regardless of whether we changed it before. (Although remembering why might go far to answering my last question below.)
>>>> 
>>>> I've describe why I think it is false precision, and can become harmful. To rephrase it, choosing too small of durations will cause harm by forcing rapid OLR updates (as in many per second.) These updates cause work for both reporting nodes and reacting nodes.
>>>> 
>>>> We could offer guidance of how to avoid that harm. Or we could choose a resolution that makes it harder to cause such harm in the first place. I think good protocol design favors the later.
>>>> 
>>>> Do you disagree with the potential for harm? Or do you see some use case for sub-second precision that I've missed?
>>>> 
>>>>