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

Magnus Westerlund via Datatracker <noreply@ietf.org> Mon, 13 May 2019 13:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E20612006F; Mon, 13 May 2019 06:41:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-6lo-deadline-time@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>, Shwetha Bhandari <shwethab@cisco.com>, 6lo-chairs@ietf.org, shwethab@cisco.com, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <155775487464.23649.5783733027851433918.idtracker@ietfa.amsl.com>
Date: Mon, 13 May 2019 06:41:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/nTuzBmrXBRP9MPvs8JxdGfaw9g4>
Subject: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 13:41:15 -0000

Magnus Westerlund 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:


The security consideration section have significant short comings as this
mechanism enables multiple ways to attack both the packet and the system to my
understanding. I would appreaciate your clarifications on these matters.

First of all by changing the dead-line so that it gets dropped because it is
already late, alternatively move the deadline time out further in time (later),
so that the forwarders may deliver it so late that the receiver considers it to

Secondly, there is the question if extensive use of this header will cause
overload or affect the scheduling of packet transmission affect other traffic
negatively. There appear to exist potential for new ways of bad interflow
interactions here.


Looking at this mechanism it appears to me as something that should fit into a
frame work, but that is not explicitly given. The main reason I am raising that
is that it appears to not care about a number of interesting and challenging
questions for a mechanism like this. Questions that a particular framework can
take care of, or which any user of this mechanism would need to consider in
their deployment before they can determine if they can safely deploy it. It
might be that some of the questions have answers and I missed. In that case
please straighten me out. And if you have some additional document that
provides more detailed usage which discuss any of these issues I would
appreciate a pointer.

So quesitons that I got when reading this specification:

1. Are there any mechanism to provide feedback if the packets reach the
receiver in time? If the sender sets the deadline shorter than the minimal
one-way path delay, then all packets will be late. Will any feedback be
provided that this is happening? In cases D=1 this appear to be a recipe for a
black hole for the traffic. One can also end up in situation where a large
fraction of the packet are late.

2. Any mechanism that exist to determine what the expected latency are from
sender to receiver?

3. Are there any type of admittance or policy approval to use this mechanism?

4. What is the relationship between traffic with a dead-line and other traffic
without a dead-line. Are traffic with a dead-line implicitly allowed to
pre-empt other traffic or at least to delay it in its queue?

5. As Barry noted, what are the protection against missuse?

These are issue that a framework or architecture would consider, I note that
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ include some
discussion of these topics. Still DETNET architecture appear more constrained
when it comes to usage than what this mechanism through its examples.