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

Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> Thu, 03 March 2016 19:23 UTC

Return-Path: <xvilajosana@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 684EA1B418C for <6tisch@ietfa.amsl.com>; Thu, 3 Mar 2016 11:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.223
X-Spam-Level: *
X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_DBL_ABUSE_BOTCC=2.5] autolearn=no
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 K1bW0IEV53kH for <6tisch@ietfa.amsl.com>; Thu, 3 Mar 2016 11:23:41 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 DE3951B4187 for <6tisch@ietf.org>; Thu, 3 Mar 2016 11:23:40 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id l68so49258360wml.0 for <6tisch@ietf.org>; Thu, 03 Mar 2016 11:23:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=bWLpG8RhtXED9cmsXwog+Rv3JseJ0JIZ+Ls96Izyizo=; b=Ckth36D9srNzyUSCc4TC6Gm7LxwMltYXjs6ahx8IBnOtA+lJQ9OZ6chHPR7CFoYtRJ UkFj1lCYW4LWjWvXTlKjZnb6XMYsdxTjwOLQoksBcF5vYNM2PqaYT6ijdcc3G51wdpgR aruw3LpsGwYfoVZP+dm/KzOvOC3pIngMADq7lCGPYOFkuzDuunA2HOc3ZaSE3CKledrf o3ts6yAlQHq94fnqXddR93Q3A45gS5GTSxND+cfMa8xV9L/trRS9RrZCCuWr3YGfX7K8 vx03NFWSF2vbole0nxraVjgMdIaK7BEkTW8K02ECMMWrvIgnzEBZpjwNhfdnEVZ3gVe7 5czw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bWLpG8RhtXED9cmsXwog+Rv3JseJ0JIZ+Ls96Izyizo=; b=ACWX278z+/uEDjzVR6aw10WdjzCHuUdigC9LITl0FiEJKGUJj7hXXHxgEQU9YqSfl3 TzmDFBdLXvubac5tioEMc7YjnLngTaCAJsI2PJ0fhOj/DscM9zDsMlqkPSN35kZj7uLF lGbh1C2/1UGbUPoVnhOsO78pLN7KwkPlMy50yZ6cvt+7OSSAs7NCga6MWh4NACL/Td5A U5HJwiFnXHq6m+rBghVWxiVG5bx56k8PGAAgLELaVwYXQOowN5A/WzX4bto4DRQx3Wq6 UD6krtQRedcJQq/2id7I1pIrtv1nPmCpW/QIXcFqqrbYf/hUx796UTp7E/CRcRpqvUFS HgrA==
X-Gm-Message-State: AD7BkJK0+MArSC+t0zh4vgnU3pLNUpIgcCHwythTNp3NaZga5cJp6w2mxxvKhIVJtU/u7jfvPAyvqZg7P/M9RQ==
MIME-Version: 1.0
X-Received: by 10.194.76.72 with SMTP id i8mr4683914wjw.117.1457033019423; Thu, 03 Mar 2016 11:23:39 -0800 (PST)
Sender: xvilajosana@gmail.com
Received: by 10.27.91.20 with HTTP; Thu, 3 Mar 2016 11:23:39 -0800 (PST)
In-Reply-To: <CAAdgstSdMJvOhMQvFZFbMhAfAu193hcmim1b=O3REkr4RZbyUg@mail.gmail.com>
References: <CAH7SZV-2kwi7UwVCKJJL6P3sb4j-osFG5OtEj22h_RRdPKHsZA@mail.gmail.com> <CAAdgstSdMJvOhMQvFZFbMhAfAu193hcmim1b=O3REkr4RZbyUg@mail.gmail.com>
Date: Thu, 3 Mar 2016 20:23:39 +0100
X-Google-Sender-Auth: q93h79IBM6wyr3dHVblXYvmg8PU
Message-ID: <CAMsDxWRNAVK+Or=9L5J4P6D7kq_dVfQ=c3x2=cqyipJWU=S92g@mail.gmail.com>
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
To: Tengfei Chang <tengfei.chang@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bb043528c8415052d29ef4e
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/4vEIJes6v0D4M697rRahyVhOgsw>
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: Thu, 03 Mar 2016 19:23:43 -0000

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>om>:

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