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

"Lijo Thomas" <lijo@cdac.in> Thu, 06 June 2019 04:15 UTC

Return-Path: <lijo@cdac.in>
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 E1D3612000E for <6lo@ietfa.amsl.com>; Wed, 5 Jun 2019 21:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 GHjaUN0_JQUj for <6lo@ietfa.amsl.com>; Wed, 5 Jun 2019 21:15:45 -0700 (PDT)
Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9154A120073 for <6lo@ietf.org>; Wed, 5 Jun 2019 21:15:44 -0700 (PDT)
Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.13.8) with ESMTP id x564FM7U028331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2019 09:45:27 +0530
Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id x564FAtZ017210; Thu, 6 Jun 2019 09:45:12 +0530
X-AuthUser: lijo
Received: from LijoPC (lijo_new_pc.tvm.cdac.in [10.176.10.234]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id x564F633031954 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jun 2019 09:45:09 +0530
From: Lijo Thomas <lijo@cdac.in>
To: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>
Cc: 6lo@ietf.org
References: <155775487464.23649.5783733027851433918.idtracker@ietfa.amsl.com> <fa1646a4-eb04-756a-c3b8-da20aa908dd1@earthlink.net> <HE1PR0701MB25222E86838A5B6397BDA2B095140@HE1PR0701MB2522.eurprd07.prod.outlook.com> <000d01d51b63$12722380$37566a80$@cdac.in> <HE1PR0701MB2522FCAED2B8B1A30177FE7595160@HE1PR0701MB2522.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB2522FCAED2B8B1A30177FE7595160@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Date: Thu, 06 Jun 2019 09:46:17 +0530
Message-ID: <000e01d51c1e$987c3090$c97491b0$@cdac.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-in
Thread-Index: AQGFF/u2Kh7sjKMZq3OrlWmFZtYbKgHHQpfuAfC27IICPFa1AAEz6twRpvTKh2A=
X-CDAC-PUNE-MailScanner-ID: x564FAtZ017210
X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean
X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1)
X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.199, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.799, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00)
X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information
X-MailScanner-ID: x564FM7U028331
X-CDAC-PUNE-MailScanner-From: lijo@cdac.in
X-CDAC-MailScanner-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/9Q5Hk1GTfZEvHEuJvUv6wECUMnw>
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, 06 Jun 2019 04:15:49 -0000

Hi Magnus,

Thanks for the great response, we will update the draft accordingly.

Thanks & Regards,
Lijo Thomas 

-----Original Message-----
From: Magnus Westerlund <magnus.westerlund@ericsson.com> 
Sent: 05 June 2019 17:23
To: Lijo Thomas <lijo@cdac.in>; 'Charlie Perkins'
<charles.perkins@earthlink.net>; 'The IESG' <iesg@ietf.org>
Cc: 6lo-chairs@ietf.org; 'Samita Chakrabarti' <samitac.ietf@gmail.com>;
'Shwetha Bhandari' <shwethab@cisco.com>; 6lo@ietf.org;
anand@ece.iisc.ernet.in; 'satish anamalamudi' <satishnaidu80@gmail.com>;
draft-ietf-6lo-deadline-time@ietf.org
Subject: Re: [6lo] Magnus Westerlund's Discuss on
draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

Hi,

Thanks for providing some background information. From my perspective I
think there are some benefit to indicate the context the solution was
developed in. Note this is really comment level and not required.



On 2019-06-05 07:54, Lijo Thomas wrote:
> Hi Magnus,
>
> Thanks for your detailed review and really appreciate your time taken 
> for the effort !!!!.
>
> Please find our below response for the frame work query addressed by you.
>
> One of the main use cases of the draft is the industrial automation 
> and control applications. The end point of such applications puts the 
> deadline information as per its delay requirements.
>  
> I agree that the underlying 6Lo network needs to ensure that the 
> deadline is met using its delay sensitive routing and scheduling 
> mechanisms while forwarding the packet along the path. The 6Lo network 
> can support such a QoS requirement through end-to-end provisioning of 
> the required network resources either centrally and/or in a distributed
fashion .
>
> In the case of a 6tisch network, one could think of setting up tracks 
> [draft-ietf-6tisch-architecture] along with delay aware Scheduling 
> Function implemented by the intermediate nodes. The deadline draft 
> works well within the context of the framework described in the 
> draft-6tisch-architecture draft. The 6tisch architecture draft defines 
> tracks which could either be set up by a centralised entity PCE or by 
> setting up tracks in a distributed fashion by reserving network 
> resources that provide end-to-end delay guarantees. Packets of 
> application flows can be sent over these tracks and scheduled based on 
> their deadlines. The CAC can be exercised where reservation fails for 
> a new track setup.  There are situations like asynchronous time 
> critical emergency messages where track set up delay is not 
> acceptable.  In such cases, we can use distributed on-the-fly 
> scheduling using 6P protocol described in RFC 8480 that takes into
consideration the deadline information.
>  
> There are several deadline based scheduling algorithms that have 
> proposed in the literature including the basic Earliest Deadline First 
> (EDF). Based on our deadline draft, we implemented this scheme over a 
> 6tisch network running on OpenWSN protocol stack and our draft 
> implementation has been merged with the OpenWSN environment for future
downloads too.
>  
> We would be happy to add some additional text specifying that ** a 
> network monitoring entity with call admission policy is expected to be 
> in place for observation and consequently better results during real
implementations**.

The proposed sentence appears problematic from two perspective. One that it
might be an overly complex solution for certain closed systems.
Secondly, is it really "call admission" rather than flow admission?

I think the right way forward here is that you document the security issues
that anyone that intend to deploy this needs to consider. I think that
discussion can discuss potential mitigations, but without specific surround
contexts it is impossible to mandate any such.

Cheers

Magnus


>
> Hope this address your few concerns and based on your response we will 
> update the draft.
>
> Happy to receive your further thoughts and valuable inputs.
>
> Thanks & Regards,
> Lijo Thomas
>
> -----Original Message-----
> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Magnus Westerlund
> Sent: 03 June 2019 18:27
> To: Charlie Perkins <charles.perkins@earthlink.net>; The IESG 
> <iesg@ietf.org>
> Cc: draft-ietf-6lo-deadline-time@ietf.org; 6lo-chairs@ietf.org; Samita 
> Chakrabarti <samitac.ietf@gmail.com>; Shwetha Bhandari 
> <shwethab@cisco.com>; 6lo@ietf.org
> Subject: Re: [6lo] Magnus Westerlund's Discuss on
> draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
>
> Hi Charlie,
>
> Please see for further comments inline.
>
> On 2019-05-30 23:16, Charlie Perkins wrote:
>> 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?
> Yes, I think so, as it points to a requirement to consider either 
> admission control or other solutions to keep the interaction on an
acceptable level.
>
>
>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> 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, there no specific first initial framework that this solution has 
> been developed to support? And you say you do not want to deal with 
> policy, and instead put that on the ones attempting to utilize it.
> Considering the security issues, and the higher layer requirements 
> that this solution appears to create I think that is far from optimal. 
> I really think this document should have a section making the 
> assumptions about its expected deployments clear.
>
>>
>>> 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.
>
> Sure, but the document could make it clear that there exist a need to 
> monitor the actual performance to know if the application will work 
> successful
>
>>
>>
>>> 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.
>
> Please do.
>
>>
>>> 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.
>
> Ok, I can agree that there is difficult to be descriptive here. As 
> long at the potential impact is a discussed security issue I think 
> this will be considered addressed.
>
>>> 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.
>
> My questions where more coming from the aspect, how do you have been 
> part of developing this technical solution without having at least one 
> framework that addresses the raised issue?
>
> Thus, my preference that in the absence of a framework to point at, 
> that the assumptions on the hypothetical framework are documented.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
>
> ----------------------------------------------------------------------
> --------------------------------------
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may 
> contain confidential and privileged information. If you are not the 
> intended recipient, please contact the sender by reply e-mail and 
> destroy all copies and the original message. Any unauthorized review, 
> use, disclosure, dissemination, forwarding, printing or copying of 
> this email is strictly prohibited and appropriate legal action will be
taken.
> ----------------------------------------------------------------------
> --------------------------------------
>
>

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------



------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------