Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 02 July 2015 14:39 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B601A891E for <6tisch@ietfa.amsl.com>; Thu, 2 Jul 2015 07:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 aVCRm3c4Gv93 for <6tisch@ietfa.amsl.com>; Thu, 2 Jul 2015 07:39:52 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510481A890E for <6tisch@ietf.org>; Thu, 2 Jul 2015 07:39:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60301; q=dns/txt; s=iport; t=1435847991; x=1437057591; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xwBjr3++4UzlJzMAGe05b3ymEWh228HIz8o8PY4szh4=; b=du7vcDSC0DLy4C7iGSIdCzPVH9lG2LtGEcMBRoQcY7KiigLT9KBxf5bs ykZqw/uzD3dmi+2QNOo8d6B+Edu+vGpGxvq8Dgk8drwFdw/5m27pDtTWH qomnVvJuWWQ3Qpal8MOIOCveVvqJHOtUoSqdkX9ti2hCWF2To1Og5T5LU 0=;
X-Files: image005.png, image006.jpg : 12176, 2532
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C4AwBXTJVV/5hdJa1BFwOCRU1UXwauIYJDjEwJgUsZAQuFLEoCHIEtOBQBAQEBAQEBgQqEIgEBAQQBAQECAR0CCAEbJQUGEAIBCAcKAQMBAQYBAQECCA4BBgMCAgIFEAoFAQsTAQMGCAEBBAEJBAQBCAaIDAMSDTq1Q5BlDYVaAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKgk2BZwEBHw0JCwwEBgECBwiCVy+BFAWFXAqOLAGDewFkhSEGgV+BOYQbi1qDPYNdJoIMHIFSbwGBAgkXBB+BAgEBAQ
X-IronPort-AV: E=Sophos;i="5.15,393,1432598400"; d="png'150?jpg'150,145?scan'150,145,208,217,150,145";a="164925648"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 02 Jul 2015 14:39:50 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t62Edot7018607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jul 2015 14:39:50 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.76]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 2 Jul 2015 09:39:49 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>, Qin Wang <qinwang6top@yahoo.com>, Nicola Accettura <nick.accettura@gmail.com>
Thread-Topic: [6tisch] draft-dujovne-6tisch-on-the-fly-05
Thread-Index: AdCzQ1M0dyQpRxt7QFa9uOtZrmFO5QALHeoAACix2YAAApHkkAAtmBzQ
Date: Thu, 02 Jul 2015 14:39:49 +0000
Deferred-Delivery: Thu, 2 Jul 2015 14:39:37 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD849EF9C42@xmb-rcd-x01.cisco.com>
References: <CAAYrgaCc78GsrUWVBtZy85ccps1Z9UhhziiuGaMB4_z3+4DTYA@mail.gmail.com> <168549437.420077.1435764505747.JavaMail.yahoo@mail.yahoo.com> <CO2PR0601MB792F534CFE7DBAC7CD6247DFEA80@CO2PR0601MB792.namprd06.prod.outlook.com>
In-Reply-To: <CO2PR0601MB792F534CFE7DBAC7CD6247DFEA80@CO2PR0601MB792.namprd06.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.49.80.35]
Content-Type: multipart/related; boundary="_005_E045AECD98228444A58C61C200AE1BD849EF9C42xmbrcdx01ciscoc_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/fD-jO-kPqYrZU9IboR4INCkxR7g>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "diego.dujovne@mail.udp.cl" <diego.dujovne@mail.udp.cl>
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2015 14:39:57 -0000

Hello Michel:

We discussed an angle of this on the call of 22 Nov 2013 recording here<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=73307867&rKey=c4a9734628e9656e> :

https://bitbucket.org/6tisch/meetings/wiki/131122_webex at 8:13<https://bitbucket.org/6tisch/meetings/wiki/131122_webex%20at%208:13>
https://bitbucket.org/6tisch/meetings/src/master/131122_webex/slides_131122_webex.ppt


In short, if the schedule is rather not busy, we can have more timeSlots per child than they really need.

In that case, the peer would only listen to the first timeSlot of a sequence of say 4. If there is no traffic there, the peer would not listen for the other 3. But if there is traffic, then the sender can indicate whether there’s more till done, in which case all the timeSlots could be used on that round.

This avoids negotiation to allocate / deallocate time slots.

Cheers,

Pascal

From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Michel Veillette
Sent: mercredi 1 juillet 2015 19:10
To: Qin Wang; Nicola Accettura
Cc: 6tisch@ietf.org; diego.dujovne@mail.udp.cl
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Hi Qin

Yes, the Frame Pending flag is defined as follow:

IEEE 802.15.4-2006 section 7.2.1.1.3
“Frame Pending subfield is 1 bit in length and shall be set to one if the device sending the frame has more data for the recipient. This subfield shall be set to zero otherwise”

This feature can be especially useful for the upstream traffic in a RPL DODAG. In a scenario where a DAG parent have dozens of children, dedicated timeslot will be infrequent and share timeslots suffer from contention. If a subset of these children have ongoing traffic, the parent can use the Frame Pending flag information to schedule temporary soft cells and avoid contention or speedup transfer.

[cid:image005.png@01D0B4E4.7402AD20]

[cid:image001.jpg@01C868D8.BF0BB7E0]

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
michel.veillette@trilliantinc.com<mailto:michel.veillette@trilliantinc.com>
www.trilliantinc.com<http://www.trilliantinc.com/>



From: Qin Wang [mailto:qinwang6top@yahoo.com]
Sent: 1 juillet 2015 11:28
To: Nicola Accettura; Michel Veillette
Cc: 6tisch@ietf.org<mailto:6tisch@ietf.org>; diego.dujovne@mail.udp.cl<mailto:diego.dujovne@mail.udp.cl>
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Hi Michel and Nicola,

I think Michel's idea is interesting. But, according to my understanding, the Frame Pending setting just means there is frame following, does not mean that the current bandwidth provided by TSCH schedule, including hard cells and soft cells, is not enough to convey those frames, and then needs more bandwidth (e.g. additional soft cells) . Right? Do I miss something?

Thanks
Qin


On Wednesday, July 1, 2015 4:03 AM, Nicola Accettura <nick.accettura@gmail.com<mailto:nick.accettura@gmail.com>> wrote:

Hi Michel,
your proposal is very interesting.

However, OTF does not allocate cells directly: it just computes the estimated number of cells to add or delete into the schedule, and then sends this information to 6top. 6top is then in charge of negotiating cells among neighbors, and meybe perform the scheme you are proposing.

So, your proposal seems fitting more the 6top-to-6top communication.
Am I missing something? What others think about?
Sincerely
Nicola

2015-06-30 8:13 GMT-07:00 Michel Veillette <Michel.Veillette@trilliantinc.com<mailto:Michel.Veillette@trilliantinc.com>>:
Hi Diego

It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and I’m not completely done yet) and I wandering if the concept of on the fly, in a single exchange, temporary allocation of a soft cell have already been discussed. For example, a node can use the Frame Pending subfield (IEEE 802.15.4-2006 section 7.2.1.1.3) to indicate the presence of packets ready to be transmitted. Based on that knowledge, the target may add an IE in an enhanced acknowledgment to allocate a temporary soft cell (e.g. single cell). Each subsequent transmission may further re-allocate a temporary soft cell. It’s important to note that the default delay for a TSCH Acknowledgment is 1ms (macTsTxAckDelay) which seem sufficient for the processing of this new IE.



This scheme is very reactive and may help dealing with non-predictable communication patterns.
What do you things?


Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
michel.veillette@trilliantinc.com<mailto:michel.veillette@trilliantinc.com>
www.trilliantinc.com<http://www.trilliantinc.com/>




_______________________________________________
6tisch mailing list
6tisch@ietf.org<mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch


_______________________________________________
6tisch mailing list
6tisch@ietf.org<mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch