Subject: [6lo] Barry Leiba's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Sun, 12 May 2019 06:54:26 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-6lo-deadline-time-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be easy to explain and clear up, but I have to ask, as I don’t see
anything about it in the document: what deters entities from using this with a
short deadline time in order to get expedited delivery, when they don’t need
it?  How does this help a network if, ultimately, every transmission specifies
a very short deadline time?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In the Introduction, please expand “BLE” on first use.

In “Terminology”, you’re citing RFC 8174, but not usng the new BCP 14
boilerplate from there.  Please copy/paste the new boilerplate.

— Section 5 —

The definition of “TU” is out of order; please move it so it’s in the same
order in the definitions as in the block.

Why is DTL the length *minus 1*?  Doesn’t that invite mistakes?  Is there a
reason not to make it the length, and to say that 0 is not a valid value?

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 12 May 2019 20:49:08 +0200

> reason not to make it the length, and to say that 0 is not a valid value?

Fundamentally, a small integer encoded into a bitfield is best encoded as a value starting from 0, instead of creating holes at the bottom *and* the top.  Also, in this case, the 4-bit value encoding DTL can be between 0 and 15, so the length in bits could be 0 to 60, which is not enough for 64 bits.
So adding one sounds fine, even if you believe holes are good.  

But then, I don’t understand why both DT and OTD are said to be “8..64” bits — that needs 15 possible values, not 16; OTL has only 3 bits (which cannot express 15 possible values, which are probably not needed anyway), and the example for OTL has a DT of 4 bits.

Grüße, Carsten

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 30 May 2019 17:00:02 -0700

Hello Barry and all,

I have made some follow-up to your comments below...

> draft-ietf-6lo-deadline-time-04: Discuss
...
> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

As mentioned in other email, I agree that we should discuss this 
problem, and I guess the right place would be in the Security 
Considerations.  I think the problem only occurs if pre-emption is 
allowed.  So one possibility would be to mandate that implementations 
SHOULD NOT pre-empt.

Designs for gaining some latency advantage by signaling often seem to 
have this problem.  Maybe there is already language we can borrow for 
clarifying the issue in our draft.

If pre-emption does not occur, then I don't think the network is 
impacted in the way that you suggest.  If every transmission specifies a 
short deadline time, then many or most packets will simply be dropped.

Will do.

> boilerplate from there.  Please copy/paste the new boilerplate.

Will do.

> order in the definitions as in the block.

Will do.

> reason not to make it the length, and to say that 0 is not a valid value?

The reason is to allow 16 hex digits for the deadline time, or 64 bits.  
You are right that this makes implementation more vulnerable to error, 
but I believe the danger here is small.  If this is a minority opinion 
and most people want to have the maximum to be 15 hex digits, we can do 
that.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 30 May 2019 19:37:28 -0700

Hello Carsten,

Thanks for pointing out that typo.  The expressions should have been 
"4..64-bit" in both cases.  It's amazing how often we can look at the 
text and still miss obvious mistakes.

Regards,
Charlie P.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 31 May 2019 08:04:11 +0100

Hi, Charlie, and thanks for the response.

> allowed.  So one possibility would be to mandate that implementations

That would help.  There's still the issue that an attacker (or just
inconsiderate use) could basically make this option useless (as you
note below) -- in such case it wouldn't actually be *worse* for the
network, but it would kill the benefits of asking for a short deadline
when you really need it.

> clarifying the issue in our draft.

The way we often deal with this is by defining options that allow
voluntary downgrading of service, but *not* elevation.  Clearly,
that's not what you're looking for here, but that works in many
situations.  You're right, of course, that allowing requests for
elevated service always prompts requests for elevated service.

> short deadline time, then many or most packets will simply be dropped.

So, in the end, I don't know what more can be said about this other
than the "SHOULD NOT pre-empt" bit... and maybe a note that if this
gets gamed, its value will approach zero, and that's just the way it
is.

> and most people want to have the maximum to be 15 hex digits, we can do

I don't feel strongly about this, and it's not at DISCUSS level, but
you can see from Alexey's question in his review, we already see
confusion.  And it's not so much that DTL starts at 0 for length one
(though it is that, somewhat) as it is that the two fields are
*different*: one starts at 0 and one starts at 1, and it seems like
the start of the rules for Fizzbin.  Clearly, because OTL needs to
represent 0, it needs to start as 1 = one.  So the question goes to
DTL: what range do you really expect to need?  Is it important enough
to get the extra 2x that it's worth adding the confusion?  If so, if
you really need the extra power of 2, then thanks for having the
discussion, and carry on.

But if it's just an issue that the extra power of 2 was possible, so
y'all did it "just in case", then please consider opting for a lower
chance of confusion.  Again, your judgment: I've made my comment, and
it's down to you now.

Thanks again for the response and for addressing my comments.
Barry