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

"Lijo Thomas" <lijo@cdac.in> Fri, 04 March 2016 12:49 UTC

Return-Path: <lijo@cdac.in>
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 BA0DD1B37D8 for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 04:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 88aIbGg08ahI for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 04:49:39 -0800 (PST)
Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id C42BC1B37E8 for <6tisch@ietf.org>; Fri, 4 Mar 2016 04:49:38 -0800 (PST)
Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id u24CnIwY016060; Fri, 4 Mar 2016 18:19:18 +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 u24CmfPu023078; Fri, 4 Mar 2016 18:18:47 +0530
X-AuthUser: lijo
Received: from CIGLIJO (cig_lijo.tvm.cdac.in [10.176.11.63]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id u24CmXqB031438 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 4 Mar 2016 18:18:34 +0530
From: Lijo Thomas <lijo@cdac.in>
To: "'Prof. Diego Dujovne'" <diego.dujovne@mail.udp.cl>
References: <CAH7SZV9aOSjAfcCb9X0+0NmHEOm7EhSHZbFefi7oB+Swj8e=kg@mail.gmail.com>
In-Reply-To: <CAH7SZV9aOSjAfcCb9X0+0NmHEOm7EhSHZbFefi7oB+Swj8e=kg@mail.gmail.com>
Date: Fri, 04 Mar 2016 18:21:43 +0530
Message-ID: <008701d17614$9f0a4950$dd1edbf0$@cdac.in>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01D17642.B8C4CF40"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFhJSLGfrjHfOWkSbk1YIEfcRUxeaAp0hhw
Content-Language: en-in
X-CDAC-PUNE-MailScanner-ID: u24CmfPu023078
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, HTML_MESSAGE 0.00, RP_MATCHES_RCVD -0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-5.299, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_00 -3.50, HTML_MESSAGE 0.00)
X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information
X-MailScanner-ID: u24CnIwY016060
X-CDAC-PUNE-MailScanner-From: lijo@cdac.in
X-CDAC-MailScanner-Spam-Status: No
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/tX5s8hG-kzaPSEQqtB30DV0cwvg>
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
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: Fri, 04 Mar 2016 12:49:41 -0000

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-step

exchange:

1- Child sends request to Parent with whitelist/blacklist of slotoffsets

2- Parent selects cells

3- Child acknowledges and finishes the transaction

The main idea is to enable an optional Piggybacking of the IE on a

data packet to reduce the number of transmitted packets, but there

are 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 <http://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.
-------------------------------------------------------------------------------------------------------------------------------