Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 04 March 2016 11:37 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 335A21B36F9 for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 03:37:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.601
X-Spam-Level:
X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 GQFnSsE6uadd for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 03:37:28 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163C51B36FA for <6tisch@ietf.org>; Fri, 4 Mar 2016 03:37:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18456; q=dns/txt; s=iport; t=1457091447; x=1458301047; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TecZDCWC62+qbMqFMYj23nfhn5lWIvuMk0/uL81Hvy4=; b=BrFION8kw2uF2KegiXHuiF5CjQh7CRfwovCeKM6pKLCdHXVT1b65KvQ3 3YknhQmeDHe4U6/18sDwzcpzGezNpMTTD8VUlJuRjAFgYpc+tTuFHnfPN WRMZGSCwV1kuuWEWwYr4gJ1riJyU0Ul+3hRCxD7T27ZjpZXSFEyKnElk7 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D4AQAdc9lW/4gNJK1TCoJuTFJtBroxAQ2BaRcBCYUkSgIcgRY4FAEBAQEBAQFkJ4RBAQEBBAEBASAKHCULEAIBCBEEAQEoAwICAiULFAkIAgQBDQUIE4gHDq4Njn0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhheEPIQPCwEBMxcJCIJCgToFlyEBhkiCBIUUgWmNF45RAR4BAUKDZGqHcDR+AQEB
X-IronPort-AV: E=Sophos;i="5.22,535,1449532800"; d="scan'208,217";a="243718252"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2016 11:37:25 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u24BbPQ2010065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 11:37:25 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 05:37:24 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 05:37:25 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tengfei Chang <tengfei.chang@gmail.com>, "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Thread-Topic: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
Thread-Index: AQHRdXTVCAuTE4LJfkSISB62qY9ol59JKCbw
Date: Fri, 04 Mar 2016 11:37:21 +0000
Deferred-Delivery: Fri, 4 Mar 2016 11:36:21 +0000
Message-ID: <9b2cc3dcdabe42e7967b0f9e1c6d28ee@XCH-RCD-001.cisco.com>
References: <CAH7SZV-2kwi7UwVCKJJL6P3sb4j-osFG5OtEj22h_RRdPKHsZA@mail.gmail.com> <CAAdgstSdMJvOhMQvFZFbMhAfAu193hcmim1b=O3REkr4RZbyUg@mail.gmail.com>
In-Reply-To: <CAAdgstSdMJvOhMQvFZFbMhAfAu193hcmim1b=O3REkr4RZbyUg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.5]
Content-Type: multipart/alternative; boundary="_000_9b2cc3dcdabe42e7967b0f9e1c6d28eeXCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/Cw4l4FyJZwnP3Xw-Se-Lwa8Yokk>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
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 11:37:33 -0000

One issue with that, Tengfei, is if the 6p response is sent but not received.

The client will retry the request for the same need of bandwidth but will get a new set of cells.
The parent that allocates cells must correlate them with a request ID (token, sequence, whatever) in case that request is retried so as to respond with the same cells.

Take care,

Pascal

From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Tengfei Chang
Sent: jeudi 3 mars 2016 18:48
To: Prof. Diego Dujovne <diego.dujovne@mail.udp.cl>
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Hello Diego,

For the Token to identify the transaction, personally, if the idea is to identify a request and a response with a token,  it can be replaced by implementing a status machine, in which the status is able to identify the status of 6P transaction.

Here is a rough example which is able to explain how Status Machine works:

Initially the status of 6P can be set as 6P_IDLE.

For a mote sending 6p request:


  1.   after the 6p request is ready to be sent which contains the candidate cell, the status turns to 6P_REQUEST_INIT
  2.  after the request is sent, the status turns to 6P_REQUEST_WAITING_RESPONSE
  3.  after received the response from parent, mote sends ACK back and add/delete cell in schedule. The status turns to 6P_IDLE
For a mote received 6p request:

  1.  after receiving the 6p request, the mote turns status to 6P_RECEIVED_REQUEST
  2.  when cells are selected or no cell is available, set status to 6P_RESPONSE_TOBESENT
  3.  after sending the response and get the ACK, mote will add/delete cells in schedule and set status back to 6P_IDLE
If the mote will not process the next 6P request if the status is correct. Even if there are some issue that the mote stuck at one status, the timeout will reset the status to 6P_IDLE.

With this, one byte can be save, though it's not that much.
What do you think?

Tengfei

On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl<mailto:diego.dujovne@mail.udp.cl>> wrote:
Dear all,
            In order to continue the discussion we left
unfinished at the Interim meeting in March 26th, I
will open a number of threads to take action on several
pending issues for the drafts:

draft-wang-6tisch-6top-sublayer-04 (which will be renamed to 6top-protocol)
draft-dujovne-6tisch-6top-sf0-00
- Regarding the use of a Token to identify transactions on
the 6top protocol, there was a proposal on the call to add
an 8-bit field to the packet header.
Do you agree with this solution?
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

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