Re: [6tsch] On the fly scheduling

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 03 October 2013 14:16 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5BA21F9360 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 07:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVNE5eTnHF2k for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 07:16:27 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0D20421F942D for <6tsch@ietf.org>; Thu, 3 Oct 2013 07:10:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13042; q=dns/txt; s=iport; t=1380809425; x=1382019025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ot5HA0BoiVoYGo2R25NMRpMaLuygL+8MHNet9jmQK/k=; b=UXJzfxV/b6ZyDrdFdKvCAIfAET5nqB1ft6eY8bkcZPzUFEjLCGZ/9PM9 oxPACa5qOobL0i714/niIVu7FgDXVjd87KsNwId+DNnIe3mzpjdBN4PKt vi8wmogy9dTjbwagYuO8AbLFfB+6VRitPZxElmN5EYlzv90LVyOV5oEhM s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAJ15TVKtJV2b/2dsb2JhbABZDoI1RDhSwT2BHhZ0giUBAQEEAQEBKhwlCxACAQgRAQMBAQsdBycLFAMGCAIEAQ0FCId+DLx0jhgBgQctAQMGAQYDgxaBBAOFT4MyoH+CZT+BcTk
X-IronPort-AV: E=Sophos; i="4.90,1026,1371081600"; d="scan'208,217"; a="267610215"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 03 Oct 2013 14:09:49 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r93E9mte028258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 14:09:49 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 3 Oct 2013 09:09:48 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "xvilajosana@eecs.berkeley.edu" <xvilajosana@eecs.berkeley.edu>, "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Thread-Topic: [6tsch] On the fly scheduling
Thread-Index: AQHOwD9pCGpYFOrKdkqRzVbO14Ql1ZnjAIxA
Date: Thu, 3 Oct 2013 14:09:48 +0000
Deferred-Delivery: Thu, 3 Oct 2013 14:09:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD8414CEBBD@xmb-rcd-x01.cisco.com>
References: <CAH7SZV86jyR6d3LbOqqFswzUN3brPdNni3GFuD-yeDYPYktNZQ@mail.gmail.com> <CALEMV4atkUjm0yRG1oOo=ayNL2jjd1ygSc_v68JuUeCpoH4+EA@mail.gmail.com>
In-Reply-To: <CALEMV4atkUjm0yRG1oOo=ayNL2jjd1ygSc_v68JuUeCpoH4+EA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.49.80.19]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] On the fly scheduling
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2013 14:16:42 -0000

+1 too.

I think that the queue size matters at enqueue but the latency is really what we care for at dequeue, that is how long did this device keep this message in queue (even if we are far from
buffer bloat conditions in such a device). If one of the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased.

I agree with Xavi that we want to avoid changing the bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis)  is to have it large amount of cells from the start but used like 10% by default (xmit/listen happens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in the ack. This can also implicitly be triggered for retries.

Please keep us tuned!

Cheers,

PS Note that Cisco has IPR on chaining time slots and flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms.

Pascal

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
Sent: jeudi 3 octobre 2013 15:46
To: Prof. Diego Dujovne
Cc: 6TSCH
Subject: Re: [6tsch] On the fly scheduling

Diego,

+1
it seems to a me a very interesting idea to explore. Maybe we can start putting some rules of this mechanism on the table and prepare a simulation. I am completely in with that idea.
Some questions arise:
1-how fast do you react to changes on the queue size to avoid hysteresis -- i.e how do you maintain certain stability in the schedule (so you don't start installing and removing links very often)
2-how you map queue size (only one or if more than one queue) to actual link requirements
3-how you recover from link collisions in case of multiple nodes schedule the same cells.
4-how to decide to who (what neighbor) install more links according to queue size?

cheers!
Xavi


On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl<mailto:diego.dujovne@mail.udp.cl>> wrote:
Dear all,
            I've been looking into the idea of "on the fly scheduling",
presented on the Sept 27th webex call as "on-the-fly decentralized reservation".
The basic mechanism would be based on analysing the queue size
on a node and dynamically adapt the number of reserved
cells to satisfy queue size, delay and/or power
consumption thresholds.
            This mechanism would work inside 6top, between pairs of nodes.
As a first approach, it would be based on the minimal draft.
What do you think on this starting point?
I (gladly) receive comments to add or modify this proposal.

                                     Diego




--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125
_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch