Re: [Anima-bootstrap] developments on 6tisch join scheduling

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 17 August 2016 01:45 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAB112B064; Tue, 16 Aug 2016 18:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6U_3wyyj_vKv; Tue, 16 Aug 2016 18:45:54 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C934212B042; Tue, 16 Aug 2016 18:45:54 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id y134so6434837pfg.3; Tue, 16 Aug 2016 18:45:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9/dtC8VGTVbAt/2+E5LRjS0UjNRkTo6BDM+om1lRYnA=; b=vavtsA+09OY35tf5OGfptfAV+5JPn2VCAqQJ0w4DV5fUirc+Jz/DrKaVzEs4hSNVwD oO8pnwWmGw0LjtQqWWu/dCtcoqOdRNjzhBlHyE6p5ZpxhyZV5ELxZ1qi59T41K4+CBRn CREyuU2SxKzUvJZzZFQcxBk7ajAF8CLMoPcZo6GFYCg/WsHrDdBvX59t3+j/TvOiizLf ZZWDFDbhoHgojW2d8dbdQpE27cCiV20fH+ke+XkM9nMMJpwozjmn/xyBincGlCcoGdED Er7tNHMelzFFmPsWCQuwotfzJ/GOzpUxGS/6pTtUOXwrXDcfNIGX8YS7ySFK9EsmpeJL 9bQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9/dtC8VGTVbAt/2+E5LRjS0UjNRkTo6BDM+om1lRYnA=; b=RSmAmdWOOPd17Ki22BERexSmf3uGfST3AiBWoPX5+IwoFfUMphspO5Zux6K27nStoq SoNPUrbPMlV+yH1Ju5CbRupY2whOtw8Rvpb2fZzAwe9HzYPMpRMfEdj6zysEokkaW/uK ELlTo2vF3lBKKd8b2I8/jd9VgCr9jqynZ/kRnQ/brgD/u5K/WtEDaODrE9/UoScfrAqY dv4TaWvKNW9gSTf45/dKwIoKrvhe4VjIn99tmiBWn+ZA4X9w4lXQ5lUJ1fpafqFWyfAe JoYn/1TmydHsn+yYAPSZvWc/dWkSAi/RgN9Qdutc2/4c3i/RJSxdcDiReesSuz69Zw7Q xhiQ==
X-Gm-Message-State: AEkoouuCt4C/bZ5DBLTekS8eyvCkkvwaP6s2uj16ZbLwgIvLfyHYZoJdZsfTVOT61KsIeA==
X-Received: by 10.98.222.70 with SMTP id h67mr69573320pfg.128.1471398354174; Tue, 16 Aug 2016 18:45:54 -0700 (PDT)
Received: from ?IPv6:2406:e007:63aa:1:28cc:dc4c:9703:6781? ([2406:e007:63aa:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 6sm42370026pab.11.2016.08.16.18.45.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Aug 2016 18:45:53 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, tisch-security <6tisch-security@ietf.org>
References: <24944.1471387601@obiwan.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <36a58fbd-22a5-7dbe-6287-5bfca0d284fd@gmail.com>
Date: Wed, 17 Aug 2016 13:45:56 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <24944.1471387601@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/Eihsop54odOFy005Bk6akhEMP6o>
Cc: anima-bootstrap@ietf.org
Subject: Re: [Anima-bootstrap] developments on 6tisch join scheduling
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2016 01:45:56 -0000

> So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy,
> but in addition, in the reply, to get some kind of number

If you are asking for *content* in a Discovery Response, you are actually
asking for GRASP rapid mode (an objective included in the response message).

I'm not suggesting that this is a problem.

Regards
   Brian


On 17/08/2016 10:46, Michael Richardson wrote:
> 
> During discussions at IETF96, it became clear that the join ordering/time
> sequence envisioned for 6tisch would be less possible than I thought.
> The bad news is that a new mechanism might be hard to actually design.
> The good news is that I think a new mechanism would put 6tisch join
> and ANIMA bootstrap almost identical.
> 
> To go back, the proposal was:
>   1) a new pledge would send a NA with an EARO, which would turn into a
>      DAC/DAR process up to the 6LBR.  The 6LBR would let the JCE know
>      about the new node through mechanism TBD.
>      The new pledge would receive a NA in reply, which, for the pledge
>      would acknowledge that they might be knocking on the right door.
>      (A network which didn't like that node would reply in some negative
>      fashion, which naturally could also be forged)
> 
>   2) the JCE would reach out (via the proxy) to the pledge, on a schedule
>      determined by the JCE.  The JCE would control the order of joining,
>      and since CoAP would be used with using something like:
>           draft-wang-6tisch-6top-protocol-00
>      all joining nodes would remain quiet except when responding to
>      queries from the JCE.
> 
> The goal of having the pledge be passive was one of bandwidth conservation,
> the JCE would enroll only as many pledges as it felt it had available
> bandwidth in the upper parts of the MESH DODAG tree.  A 6tisch network might
> allocate a rather small amount of bandwidth for join messages, and utilizing
> the bandwidth responsabily is important.  That means never wasting any energy
> among the lower parts of the DODAG when the packets would just get dropped
> further upwards.
> 
> In discussions, it appears that the EARO as described in
> draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID
> of draft-sarikaya-6lo-ap-nd-02, and the process is slightly different.
> 
> One additional reason why the passive pledge turns out to be a problem is
> that the JCE does not actually know the wake/sleep schedule for the pledge.
> In the 6tisch case, it ought to be possible for the pledge to sync up to
> the schedule and so the proxy will know when it can transmit to it, but
> in order to keep the proxy from having to store a lot of data coming from the
> JCE, the JCE also needs to know the schedule out at the edge.  This does not
> seem unsolveable, but it was an additional concern raised.
> 
> Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP
> discovery (or DNSSD) to find a proxy.  The new pledge uses the proxy to
> initiate an EST session using the proxy.  The enrollment process in the ANIMA
> case is driven by the pledge, on the assumption that the ANIMA ACP has
> sufficient bandwidth for normal congestion control present in TCP and CoAP to
> deal with a limits.
> 
> What is needed is a way to adjust things so that the pledges will attempt to
> join in a way that does not overwhelm the network, and more so, that the proxy
> nodes can easily police that they are doing so.
> 
> So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy,
> but in addition, in the reply, to get some kind of number to seed a backoff
> algorithm that causes the pledge to attempt to initiate the join process
> at times deterministic to the network.  I'm not talking about an exponential
> backoff.
> 
> This is where the hard part is, how to come up with a simple to describe, and
> simple to code algorithm which would fill up the available bandwidth, and be
> easily subdividable.
> 
> By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at
> rank 3, that it would be able to easily pass some percent of that bandwidth
> to a new proxy at rank 4 in a way that does not mean reconfiguring the entire
> mesh to delegate bandwidth.
> 
> Removing the subdivable property, some simple pseudo-random number generator,
> with the right seed would be the right idea.   A good PRNG ought to span
> the available time space evenly.  I don't have a solution, but I'm trying to
> write up the requirements more clearly.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> Anima-bootstrap@ietf.org
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>