[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: https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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 late. 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.
- [6lo] Magnus Westerlund's Discuss on draft-ietf-6… Magnus Westerlund via Datatracker
- Re: [6lo] Magnus Westerlund's Discuss on draft-ie… Charlie Perkins
- Re: [6lo] Magnus Westerlund's Discuss on draft-ie… Magnus Westerlund
- Re: [6lo] Magnus Westerlund's Discuss on draft-ie… Lijo Thomas
- Re: [6lo] Magnus Westerlund's Discuss on draft-ie… Lijo Thomas
- Re: [6lo] Magnus Westerlund's Discuss on draft-ie… Magnus Westerlund