Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

Qin Wang <qinwang6top@yahoo.com> Wed, 09 March 2016 16:30 UTC

Return-Path: <qinwang6top@yahoo.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4690D12D717 for <6tisch@ietfa.amsl.com>; Wed, 9 Mar 2016 08:30:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHsQ9VH-iI3X for <6tisch@ietfa.amsl.com>; Wed, 9 Mar 2016 08:30:00 -0800 (PST)
Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) (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 501B812D6DF for <6tisch@ietf.org>; Wed, 9 Mar 2016 08:30:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1457540999; bh=ojgmysxOX0Lkq9M5BYlsFHfFp2KI8gTEIkhpo8Xa2B4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=h7hdpdB0U9iVz8CM+NAJ7JbOUG/q2k1lrzoWxkdKlsnxkanl6++R1AiteMNhaMEmPfxo58nei+iGP2HI6lzPi7bLC8QUiuNn4zW9ql6DWFY/h56iN/wSw04LiiMIWo+0xnmQoYi8C84LBGRnFhTKzDI1h7CIfBbKGbVs4sk7UgqDhp/RjzekLa1R0TEnkuWn/eUdSdiqIhcILQ1VLEV8ZzkOMRQMVu8OSFo6Pk31/xo2TzqU4TBkIM3SvwQKqrPviDx0NySGsgC/A85Q5Vh/yWGBhtYAW9VvdTwWz3G5ZlCmw/uVEizHvKEG+hRW8AayugAi/kPiTU7zTqdIwYXOkA==
Received: from [98.139.170.181] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2016 16:29:59 -0000
Received: from [98.139.212.245] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 09 Mar 2016 16:29:59 -0000
Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 09 Mar 2016 16:29:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 290384.90912.bm@omp1054.mail.bf1.yahoo.com
X-YMail-OSG: A7_ffR8VM1kmGSOnn3KglkzG6K8hraxfrzxJHcoBBvBq9FMPDeNYBgYsYD8g.YD PS4Dd8bwY2RCQJ5y8dw9IZ_0Z23q1zX9HAxKOf6VUrLKELWk_rGOhvhBE5OSBfIEj0BLe8CGqkeU KExN9NQfRNAq.Ubxq2Ve.1A9RhSx.p30e2X4xGbjXYgHm0fKuotn5di9wSKuQG4.hZ9ZNWOtKJHO jlImWUecOROZu8jLVHt_f_uSH8fBYJN76bQSVNEz_rdlVf5kO3JUjjxciM_53cC.JAFt0SBfDh3D _vKl91OxLrNdivHc5GneIWdlwPV8MaWBtDjJPa.IXY9wVOFyuzj7HQcVi9cS9yyByCXbk0t1gpr3 KnyGIc2cfqy4iaItBHNlqPnbmU7O6bMCN0EnzHlG35tuydyVCNzFCKSUwmpJQ4pYEIzDZm8y9Djl 1WRcvYPULR38k0HEOoRoB8QRroVzFaE2NR3Y8wmbl9DGESwTvijS1Iwnfbs0WuSENXBzU5oPtAUR _X4pP5ugV2wbdqvqh
Received: by 66.196.80.113; Wed, 09 Mar 2016 16:29:58 +0000
Date: Wed, 9 Mar 2016 16:29:37 +0000 (UTC)
From: Qin Wang <qinwang6top@yahoo.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Message-ID: <1156729211.6853109.1457540977549.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <9162F00F-D55B-4915-852F-ECC378AECBDB@cisco.com>
References: <9162F00F-D55B-4915-852F-ECC378AECBDB@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_6853107_1723681732.1457540977521"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/KIoA43ZQLLm6ZB5K4ZtFQ2Q3pho>
Cc: Lijo Thomas <lijo@cdac.in>, "6tisch@ietf.org" <6tisch@ietf.org>, "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Qin Wang <qinwang6top@yahoo.com>
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: Wed, 09 Mar 2016 16:30:03 -0000

Hi Pascal,
I want confirm what I understood.(1) Both step1 and step2 are extra message besides ADD/DELETE message exchange(2) Because the step1 and step2, Child will know which cells it can use. Then, when the child wants more cells,  the child selects the cells from those set as UNUSED in the bitmap, as candidates, and send ADD request to parent. And the parent will send Response to confirm. That is 2-stages, instead of 3-stages message exchange.
ThanksQin

 

    On Wednesday, March 9, 2016 3:05 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
 

 Hello Qin:
Please consider the message by Tero.
The ack is Mac-layer before upper layer processing and does not guarantee success in the stack.

What we'd really want is suppress the MAC layer ack but not the 6P response.
Another angle (for the sake of making sure we left no stone unturned).
If we think transactionality is too difficult to achieve and that parent/child may lose sync: it is possible to avoid the issues with transactionality by using a bitmap to represent cells like LoRa does with frequencies. 
Step 1 the parent provides a list of cells (say 16) that it may allocate to that child in the future. The list may differ per child and may overlap with other children to enable to parent to temporarily give a cell to one child or another.
Step 2 (runtime) the parent sends the bitmap of the cells, bit set if the cell is use child to parent. If this is sent regularly like a frame relay full status, things will eventually sync.
What do you think?

Pascal
Le 8 mars 2016 à 22:34, Qin Wang <qinwang6top@yahoo.com> a écrit :


Hi Diego,
I also have question regarding to the third message, i.e. Child acknowledge. 
In this case, the Child must accept the selected cells in the Parent's message if it received the message. Right? In another word, if the Parent knows the Child has received the message correctly, the Parent can be sure that the selected cells will be added/deleted into/from the Child's schedule. Since the MAC layer ACK can tell Parent the Child has received its message correctly, I think there is no need for the Child to send back the 6P layer Acknowledgement.
Do I miss something?
ThanksQin

On Friday, March 4, 2016 7:51 AM, Lijo Thomas <lijo@cdac.in> wrote:


#yiv8088234616 -- filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8088234616 filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8088234616 filtered {panose-1:2 11 6 3 2 2 2 2 2 4;}#yiv8088234616 filtered {panose-1:2 5 6 4 5 5 5 2 2 4;}#yiv8088234616 p.yiv8088234616MsoNormal, #yiv8088234616 li.yiv8088234616MsoNormal, #yiv8088234616 div.yiv8088234616MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8088234616 a:link, #yiv8088234616 span.yiv8088234616MsoHyperlink {color:blue;text-decoration:underline;}#yiv8088234616 a:visited, #yiv8088234616 span.yiv8088234616MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8088234616 span.yiv8088234616EmailStyle17 {color:#1F497D;}#yiv8088234616 span.yiv8088234616EmailStyle18 {color:#833C0B;}#yiv8088234616 .yiv8088234616MsoChpDefault {font-size:10.0pt;}#yiv8088234616 filtered {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv8088234616 div.yiv8088234616WordSection1 {}#yiv8088234616 Hi Diego,  Do we really require 3 transactions for 6P operations as mentioned.   The second transaction from the parent contains all the required information  for the task. In case the 2nd packet is lost, the parent will schedule a RX link which will be unutilized for the time being and can be reallocated depending on the scheduling function. But if the 3rd transaction is lost, the client will allocate the TX link  and will start transmitting packets. So can we avoid the ACK packet(3rd transaction) from the client, or is there any added benefit.  Thanks & Regards,Lijo Thomas     From: 6tisch [mailto:6tisch-bounces@ietf.org]On Behalf Of Prof. Diego Dujovne
Sent: 03 March 2016 21:11
To: 6tisch@ietf.org
Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Dear all,            Given that there is parent preference in cell
selection, a child-initiated transaction triggers a three-stepexchange:1- Child sends request to Parent with whitelist/blacklist of slotoffsets2- Parent selects cells3- Child acknowledges and finishes the transactionThe main idea is to enable an optional Piggybacking of the IE on adata packet to reduce the number of transmitted packets, but thereare latency concerns when the (data) traffic is low.Is it worth to enable this option given the added complexity?Regards,                                Diego Dujovne
-- DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
-------------------------------------------------------------------------------------------------------------------------------
[ 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. 
-------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch




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