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

Tengfei Chang <tengfei.chang@gmail.com> Fri, 04 March 2016 08:17 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 026601B34B6 for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 00:17:13 -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 qbiZA_0n8hTG for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 00:17:10 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 70C591B311E for <6tisch@ietf.org>; Fri, 4 Mar 2016 00:17:10 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id g127so39017057ywf.2 for <6tisch@ietf.org>; Fri, 04 Mar 2016 00:17:10 -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=GTzm885w8Fwyk7C1NG6v/c9ozuYyCsV1Kl1COaTMybA=; b=mgruDp/CXDPIkSocYnnAZcg7QllLGA1iIs3/wvzthPXLW7oL0vPusY7PX0tBqq8QG9 UrO3bWJVDa3Y09x9DGGSYcyiA7vb2LalajeNnodKm03oU6T9WV6tsQ8IfOv6HQ883/uU sa49MZD59/BE+WUxfkuWihs7Fs2DC+vmjGZNk2irsvTD7Y+OYpsm8/3TzBU6eMf2aVkZ tnZcziV9PATYJ2kyA5jHPvd74xhFzHdBmM76SRtohnSN81BiZYHakKC4ngbT4QAeh2Wg NnBFhZxO/Z7yNadcLEN/M8jhEz2BVY6Ye3cj4PYiqDM6Ea9lXy+Pf5R9hIA7qxRTBXQD Iuww==
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=GTzm885w8Fwyk7C1NG6v/c9ozuYyCsV1Kl1COaTMybA=; b=YAd8SklQ/YGNH94E5Mg+5AxEJHv77yl3HvZ9VWTn1je/g+79zYMc4jlq2PDlOaQ6XQ VDVjmt3QYJw/O7svD1fXNKnAZ5PFg4w9KFybZ2kHsoFYP0SOPn+OLtoPqLHBnnQ0qH4B B7p8/p7pX4jUfJADqhhJ1d/DmVJHKH1P74JXmywNarYO9JYoE6Z0i11PuweuIogQkYBW QG8ZVDWXMfAwM49MWBl+hIfTY0dT7l1+WA6VW1wbXaR/LZPVCBR5G6kdrMbqHytVh5hs Hjx7QQWBEJt3AiWbS+b7s0iVEK8hSzqr3+GtoQQsXJ/8QCao24iC4CTXmm+IVGKQr1sY QxRw==
X-Gm-Message-State: AD7BkJJAAUO7mgx/AV3gWGpx7GS/b0iq58tOKKEVBS+7fQs4km1Xap7ADS0HYP2XKV4z112SXRBrDa4+FYbcbA==
MIME-Version: 1.0
X-Received: by 10.129.108.88 with SMTP id h85mr3926045ywc.31.1457079429769; Fri, 04 Mar 2016 00:17:09 -0800 (PST)
Received: by 10.37.116.151 with HTTP; Fri, 4 Mar 2016 00:17:09 -0800 (PST)
In-Reply-To: <CAMsDxWRNAVK+Or=9L5J4P6D7kq_dVfQ=c3x2=cqyipJWU=S92g@mail.gmail.com>
References: <CAH7SZV-2kwi7UwVCKJJL6P3sb4j-osFG5OtEj22h_RRdPKHsZA@mail.gmail.com> <CAAdgstSdMJvOhMQvFZFbMhAfAu193hcmim1b=O3REkr4RZbyUg@mail.gmail.com> <CAMsDxWRNAVK+Or=9L5J4P6D7kq_dVfQ=c3x2=cqyipJWU=S92g@mail.gmail.com>
Date: Fri, 04 Mar 2016 09:17:09 +0100
Message-ID: <CAAdgstSpEENn+e14FD9zXQZZdkEBn05_SLoSjP4rxJzq33-DeA@mail.gmail.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary="001a114d88f0d234df052d34bd0b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/A83R9dPaINJr99O9wMsmHFM9xF0>
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 08:17:13 -0000

Hi Xavi,

Thanks for explanation! It makes sense for me.

Xavi, Diego, All,

Does the token indicates the ID of one transaction? How this 8-bits value
changes during a transaction/multiple transaction? It would be helpful if
there is some martial showing how the token works with 6p. Let me know if
there is also a discussion somewhere which I can trace. Thanks!

Tengfei

On Thu, Mar 3, 2016 at 8:23 PM, Xavier Vilajosana <
xvilajosana@eecs.berkeley.edu> wrote:

> Hi Tengfei,
>
> if we want (now or in the future) to support asynchronous responses (such
> as the piggybacking case or if we want to aggregate confirmations) then the
> token is handy. If we think that this mechanism will always be synchronous
> and that concurrency will not be allowed then the state machine works.
>
> my 2 cents :)
> X
>
>
> 2016-03-03 18:47 GMT+01:00 Tengfei Chang <tengfei.chang@gmail.com>:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>