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

Barry Leiba <> Fri, 31 May 2019 07:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AC0512008D; Fri, 31 May 2019 00:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fs-ydnYpYzS3; Fri, 31 May 2019 00:04:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D492E12003F; Fri, 31 May 2019 00:04:23 -0700 (PDT)
Received: by with SMTP id u186so13647488ith.0; Fri, 31 May 2019 00:04:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/n1b5NdbROgFQSMTkrQIfLIaCs4HQMF57dPv3B3b7wc=; b=NCbjMMRByNrnCqJTdT8Ti1bxc0VxQX0wTTq7oxjF1gXDuV5rykndEKz1G6e0KUyd+Z l5FM75n2WWE4mTN43V2ZoEZEVVPgBTLhJGkcRJ6Jcu3AkQ+vTCKl7Ao99C2lH9EmB7TJ oSljSrcPqlj/iZMe9/TyrL9jRldrQQrK0iNSwgaBK72kQ2FbRyHSOLh1pWLMeXA6sPkE Elwqp6gd20SAnJujZMvP2p74NGA77d3B+rFTc48SrCJFTKEReUE0/ts3oVj2Zbq8qeV4 Czl5slcrrdO3GpeFVp9pp0E7+P1k9/BOSmE7N74SJiB8XJeRUoUSORIdvmvb4yiejSAA O1gg==
X-Gm-Message-State: APjAAAWM1qGX2FIrbHZzVBH2Ogfd5YKHbx/qn4MIhJM1QJLJEUyK8UgJ 6n2DkxyH3YQjBETqLvESiP+HxCpLifDEFA6lcaI=
X-Google-Smtp-Source: APXvYqxzXpmeykHFcNYbkgo6Z6V2Ed2eaJDNCnYIgxLM53J3imJhRz8YWpy1t406cr9/TEFnkXvz3X2XWO4juvIA2Cc=
X-Received: by 2002:a24:4d87:: with SMTP id l129mr5837947itb.80.1559286262543; Fri, 31 May 2019 00:04:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Fri, 31 May 2019 08:04:11 +0100
Message-ID: <>
To: Charlie Perkins <>
Cc: The IESG <>,,, Samita Chakrabarti <>, Shwetha Bhandari <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [6lo] Barry Leiba's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 May 2019 07:04:25 -0000

Hi, Charlie, and thanks for the response.

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

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.

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

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.

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

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

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

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.