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

Charlie Perkins <charles.perkins@earthlink.net> Thu, 30 May 2019 21:15 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AC212016F; Thu, 30 May 2019 14:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwy1FqWv08yY; Thu, 30 May 2019 14:15:56 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F44A120163; Thu, 30 May 2019 14:15:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1559250956; bh=JieXbTnCxrY/3+v9Xhbhj81EBos/By7JoS7+ D32Pnt4=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=KzkQF9gFzte5Xlu3I1WGUKX+EDj7hpZVMsV0RHHejy3A6y cOmrGd6LMibBmprPsDzmWIsGDl1dqle86AisuDdL0/g5H31MjlqUHNqlvtsCs4dP/Ji o3xgUHsrZ9mkhS//yD42QB6B7vulEqTDRgwo7UBHVk8bPMA83GdJCo9anFralMUS3A1 FdEPaLYz2cpA5qjjkxZWAirtCJgicXzrLUDfteJ77A68oHurqLJL6CNSPzUWSIsE0Oq 44txUZqbGOUIMNUuIEFGC0mvzluzdQmhEhuY/kFcviar34TsBoXQ5FZMJJlIedf61pA sW7XcbkPI8KigMYgGbY3D3bTCkxw==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=Y6xzBGZ2vyxaiCAwCB/eIGZd3PqPk+p9bRwqA0A1sNf9GmwPFJffIgLFZjDhxVvpk/NIjZ6AzwASFrdVWSM50eqTo6l5XsqJ+neyknTTUbsfA4DTU1um6q0QG/hS2+nGuJm96YC8FeRLw5sDxrmTcyn7Rz4KW8mLTd2dupQ9hLhzP8oPvbDNaD/ivIvi3A9ZpBnhhUGKRyoY5b/qMsVH/8GrUoEKYRR+B5I5H9UXeCLltSyh7LA6x/ysirDLkfr0brKOUJnlRzY4pXPIjgUaZemy5cBMjTdpn0Qd0LKjkksXLGhaK2km0epuIFKc17nFxPdhwS1boBh/iYga1o2KmA==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charles.perkins@earthlink.net>) id 1hWSOw-000CvX-Qs; Thu, 30 May 2019 17:15:54 -0400
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, 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, 6lo@ietf.org
References: <155775487464.23649.5783733027851433918.idtracker@ietfa.amsl.com>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <fa1646a4-eb04-756a-c3b8-da20aa908dd1@earthlink.net>
Date: Thu, 30 May 2019 14:15:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <155775487464.23649.5783733027851433918.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95854a0daf6dddbfa0c08a74e1404723d6350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/uQD2IeWiYu44hoG850zi8U-fFL8>
Subject: Re: [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
Precedence: list
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: Thu, 30 May 2019 21:15:59 -0000

On 5/13/2019 6:41 AM, Magnus Westerlund via Datatracker wrote:
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-6lo-deadline-time-04: Discuss
>
>
>
>
> ----------------------------------------------------------------------
> 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.

Agreed that this vulnerability should be mentioned in the Security 
Considerations.


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

If other packet transmissions have to be pre-empted in order for the 
deadline to be met for a particular packet, then indeed this could 
affect other traffic.  It is also a matter of possible interest what 
might happen if there were two packets in the transmission queue with 
the same or different deadlines.  However, the processing in these cases 
is a local matter at each intermediate point, and out of scope for this 
draft.   Does this also belong to be mentioned in the Security 
Considerations?


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

This mechanism is a simple kind of signaling that could fit into various 
frameworks, and exploring that space would be pretty interesting.  But 
it would represent a huge digression away from the point of this draft, 
which all along was intended to offer a simple mechanisms without 
getting involved with messy issues of policy.  If there is something 
missing in the basic mechanism, then that should be fixed.  But I don't 
see what is missing.  Some of the discussion below is also relevant to 
this point.


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

This kind of signaling is far more appropriate at the application 
level.  To fully characterize the expected distribution of latency 
values is out of scope for the draft, and the information needed would 
usually depend on the application.  Some applications don't care much 
for dropped packets but don't want to handle packets coming in too 
late.  For other applications, knowing the distribution would allow for 
setting a deadline that would usually all reception of 85% of the 
packets (or some percentage predetermined by the application).  It's 
hard for me to see that as in scope for our draft.



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

As above, I think this is most properly handled by the application.


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

The policy details are out of scope for this draft.  However, it might 
be worthwhile to mention that (similar to many QoS efforts) care must be 
taken to avoid abuse.


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


We don't specify that, and since it's a local matter at each node, a 
mandate would be unenforceable.  However, if it is important, we could 
design an advisory extension to the draft for this purpose.  The problem 
is that the application should not necessarily need to be involved with 
changing its behavior in response to (highly dynamic) traffic conditions.

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


I think it would be best to enlarge the discussion in the draft to 
explain about the potential for abuse.  I don't see just how the simple 
mechanism at the level of 6LoRH should be charged with the 
responsibility for an entire framework, and I really hope that simple 
mechanisms such as this one can be found to have value even without 
specification of a much larger set of protections and repairs.

Regards,
Charlie P.

>
>
>