Subject: [Dime] DOIC WGLC: duration unit

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Dec 2014 22:55:51 -0600

We currently define the unit for OC-Validity-Duration as milliseconds.

Section 4.2.3 says (in a note) that transit time for OLRs can be safely ignored. That is likely true if the validity durations can generally be assumed to be long in comparison to transit time. It is _not_ true if validity duration can be a small number of milliseconds. That could lead to situations where the reporting node thinks the report has expired before the reacting node even sees it.

Really, I don't think milliseconds are a reasonable unit here. I can't imagine any useful and safe application for sub-second validity durations, nor can I imagine it ever being useful to distinguish between X seconds and X + 0.001 seconds. We should choose a unit that lends itself to reasonable value ranges. I suggest we change it to seconds.

Thanks!

/Ben.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 08:31:20 -0600

Why not change the paragraph in section 4.2.3 to indicate that the 
transit time should be taken into consideration when setting validity 
duration to a small number or milliseconds?

Steve

On 12/16/14, 10:55 PM, Ben Campbell wrote:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 10:30:45 -0600

Why would you ever set validity duration to a small number of milliseconds?

I think asking nodes to take transit time into consideration adds considerable complexity.

> On Dec 17, 2014, at 8:31 AM, Steve Donovan <[email-masked]> wrote:
> 
> Why not change the paragraph in section 4.2.3 to indicate that the transit time should be taken into consideration when setting validity duration to a small number or milliseconds?
> 
> Steve
>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 10:43:39 -0600

> Why would you ever set validity duration to a small number of milliseconds?
Why not?
> I think asking nodes to take transit time into consideration adds considerable complexity.
I don't see that saying that validity duration values less then the RTT 
should be avoided is adding considerable complexity.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 11:28:55 -0600

> On Dec 17, 2014, at 10:43 AM, Steve Donovan <[email-masked]> wrote:
> 
> 

Because it's false precision. It's more likely to be harmful than useful. The precision of a value should be appropriate for it's the precision of its measurement. Inappropriate precision leads to bad decisions. [1]

The validity duration means one of two things, or a combination of them: 1) I estimate that I will be overloaded for roughly X time and/or 2) I will tell you if I am still overloaded, with sufficient notice you can reasonably act on it before the expiration.

(Of the two, I think 2) is the more realistic.)

For 1: If we think we can estimate how long it you are likely to be overloaded down to sub-second precision, I'd like to see the magic prediction algorithm.

For 2: Sub second validity durations require multiple updates a second to refresh the OLR state. That creates a _lot_ of almost certainly useless work for the reacting node.

[1] http://en.wikipedia.org/wiki/False_precision

> I don't see that saying that validity duration values less then the RTT should be avoided is adding considerable complexity.

We currently don't have a requirement to estimate RTT, other than "we assume it's not crazy big." This would add one.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 12:40:40 -0600

I don't feel strongly one way or the other.  This was changed based on 
discussions at the interim meeting.  I believe Maria Cruz originally 
proposed it.

One other approach, if we don't want to support durations of .001 
seconds would be to put a minimum duration but allow millisecond 
granularity above that.

I'll step out of the argument and let someone else be champion for 
millisecond granularity.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 13:03:50 -0600

> On Dec 17, 2014, at 12:40 PM, Steve Donovan <[email-masked]> wrote:
> 
> I don't feel strongly one way or the other.  This was changed based on discussions at the interim meeting.  I believe Maria Cruz originally proposed it.
> 
> One other approach, if we don't want to support durations of .001 seconds would be to put a minimum duration but allow millisecond granularity above that.

That brings up the question about whether there is any point to distinguish a duration of X from a duration of X+.001. My gut tells me that's still a false precision problem.

(Honestly, I think 1 second precision is pushing it, but the next natural resolution is 1 minute, which seems too blunt. We could do something like units of 10s, but I suspect that would be counter-intuitive enough to cause implementation errors.)

> 
> 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?

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Dec 2014 01:01:11 +0200

[snip]

> 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.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 17:07:38 -0600

> On Dec 17, 2014, at 5:01 PM, Jouni Korhonen <[email-masked]> wrote:
> 
> [snip]
> 
> 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?

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 18 Dec 2014 17:11:14 +0000

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Dec 2014 17:47:06 -0600

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,
>

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 22 Dec 2014 21:59:30 +0000

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,

Thanks!

Ben.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 29 Dec 2014 10:40:45 -0600

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