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

Tengfei Chang <tengfei.chang@gmail.com> Fri, 04 March 2016 13:06 UTC

Return-Path: <tengfei.chang@gmail.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 154681B37EB for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 05:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 vN03pVlfXrp6 for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 05:06:29 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 5997A1A92B7 for <6tisch@ietf.org>; Fri, 4 Mar 2016 05:06:29 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id i131so30408655ywc.3 for <6tisch@ietf.org>; Fri, 04 Mar 2016 05:06:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=daMgIckDcKV7HDY/t6Cmmo8ZW0GnLl2SRc7azl9VOHU=; b=kakiVI23O04aFLooN/eikpTcVQtrC2Zy3raPRfmxlHr2nU48bvNm4XKjSSW0gqDGFw Nx+bbDx87HXbcPQbIU/2VLwWLPMDxwZL+GHL1zX+coTmcF37CiscbnilR0lWyHCNbcuE VxY3wvHDlxTYffL/WWXRReCYsPqFX9p+zo9N90aCUNQI2n2JWsRCE26rWi/sHL4srYCW E7sqk1n6/j3iTTU10iIKoX523IZv2+0kvmw9zSG7dYwFlo9bllxEB6svUHhsekI1O6UX lLKteXWM2wmNa+emxORmcQuKqokm6sDLw1YWMPwmJL69EVl7HzP7TiirVVMkE7qnmTPL ObXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=daMgIckDcKV7HDY/t6Cmmo8ZW0GnLl2SRc7azl9VOHU=; b=BeXfrHuMWqiEwc0aa4f4DgjWFu+hiQJc/BPr5GZLJsqX3/dQYwQ7jDuUZ9DfkauroK KxCtvNmxVNgicbOpRFavQ0Pml9lrmVWoG3t9dY2J2WSc/V312BGPayKi7Zc4+2kJoTMP ugS0tpWeDoQ5Axg6OTgEjIPuRj+nL+29EB4MUP0W468cv/iNMgECwridJIa4jkbI930k RtiU/oKX1PdH1LPSYY+SCD9aeKFZ5sfAyynztCImzkQhR12TP+pW4QYhd0mMZTShgdeq Of+J6KVUGrxWdEjJ8BirZX4ayxPNNkkLZ6dpkZtinV/j/v2RW6tgQAMjditq3kkkPQYJ Y+EA==
X-Gm-Message-State: AD7BkJK8DT14N4mw3OOUnB2Oe2epdI15EJOxbmrz3x6GSS4IfSlTWmWnzYpaDppoQ85shXxXo9qwzM5N70Tkag==
MIME-Version: 1.0
X-Received: by 10.129.145.82 with SMTP id i79mr4567628ywg.345.1457096788607; Fri, 04 Mar 2016 05:06:28 -0800 (PST)
Received: by 10.37.116.151 with HTTP; Fri, 4 Mar 2016 05:06:28 -0800 (PST)
In-Reply-To: <9b2cc3dcdabe42e7967b0f9e1c6d28ee@XCH-RCD-001.cisco.com>
References: <CAH7SZV-2kwi7UwVCKJJL6P3sb4j-osFG5OtEj22h_RRdPKHsZA@mail.gmail.com> <CAAdgstSdMJvOhMQvFZFbMhAfAu193hcmim1b=O3REkr4RZbyUg@mail.gmail.com> <9b2cc3dcdabe42e7967b0f9e1c6d28ee@XCH-RCD-001.cisco.com>
Date: Fri, 4 Mar 2016 14:06:28 +0100
Message-ID: <CAAdgstRNx4oKCWoQTcVDFM=KPeZ69fH6=yx5=OyX1R62aEcS3A@mail.gmail.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=94eb2c093a3e7d3447052d38c89d
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/3NNlSi_TWbXg61e3lbxJqTe5Gts>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
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 13:06:32 -0000

Hi Pascal,

The parent should allocate cells only when it received the ACK of the
response. If no ACK received, no cell will be allocated. This can be
handled by state machine, though it doesn't support concurrency.

Tengfei

On Fri, Mar 4, 2016 at 12:37 PM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> 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> 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
> (56 2) 676 8125
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>