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

Tengfei Chang <tengfei.chang@gmail.com> Sun, 13 March 2016 08:40 UTC

Return-Path: <tengfei.chang@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A3312D99A for <6tisch@ietfa.amsl.com>; Sun, 13 Mar 2016 00:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 f7PoNlXW96vh for <6tisch@ietfa.amsl.com>; Sun, 13 Mar 2016 00:40:51 -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 1905012D987 for <6tisch@ietf.org>; Sun, 13 Mar 2016 00:40:51 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id g127so136077421ywf.2 for <6tisch@ietf.org>; Sun, 13 Mar 2016 00:40:51 -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=wIxVUTQQfm/num5Q4voDJUeeKl2+ziZTU/aXssD8E90=; b=yI82W0FYQykQOWzfy3y6D83JxhQN9MkqUHwVHVHkytNMe54GqCJV63Fjx8vsDfQNKK NrKw4743ttXp83CkrRACu80wTB3y/78JqckCuAwXInieIIvM0o2Ia025u0hee5/kHac1 iy+UDjq2OiC2HX0Hui6qCN2F+uykJNIICWRo4U9smfZlWze3M3OHVPQ3OQdmdHgbnvPZ zwgiga9To72JB+ovwll1RcM3FKhIZbkBmoa8qo2g3pmJcBwHss+6P34japDAfBMHf1aZ 6JucmajPStfsQAQ49ZrSMqEoEFa2G6omthHT6FO9QsuPNnMdwMOXzWmzXiwaepHG9aDQ vJHA==
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=wIxVUTQQfm/num5Q4voDJUeeKl2+ziZTU/aXssD8E90=; b=U5Z97sVxpDwjtBB3JY2IF4f0TtPHyhsisu4dvuKeudVWGgd2yxuCCDkOqYFlFc2U36 Ns95DKPH5UObdxopZyzMJYSuNq67Wz3y/WrHWS9+WX5ZyKeI0MVsvO1dUPwqfADBKPgW VellO8i+oxfKbuvrYLmLNSG2CPNcn9Yd/b5zipjPF0moQPhdYxGN/Sp6lPlOuNfgGA7N QNCSNBZ12EuLOXrNblb0fuPw6ZWK0XQG/lijSeQqtS+U+2QMIuzdAMGK8NmccWQl5dDJ Zzvp8hQH7oJHDuieS+WM5rrsg4Jwbvy1ap7uyD7x4P9GW9cMD58VUpMYdhTb/dmnkqzt oPGA==
X-Gm-Message-State: AD7BkJIwBd82st06nvtfjevZtVO7fSmfFbTfAL6jvxGST0emnfU7EHiq0HYEYt4ITaark99rzdCw5otywx6nJA==
MIME-Version: 1.0
X-Received: by 10.13.239.68 with SMTP id y65mr9130027ywe.230.1457858450360; Sun, 13 Mar 2016 00:40:50 -0800 (PST)
Received: by 10.37.230.214 with HTTP; Sun, 13 Mar 2016 00:40:50 -0800 (PST)
In-Reply-To: <CAH7SZV94JZSWoMpWE9C2EGHwnSR9RhNEjFcdTv+GQrJ8oaKPhw@mail.gmail.com>
References: <83F03D1D-FC7D-4502-80D5-9793DDE02DDF@cisco.com> <799700602.6733178.1457538467013.JavaMail.yahoo@mail.yahoo.com> <9d40e7f8ac2c486cb338deb6eeeb54f2@XCH-RCD-001.cisco.com> <CAH7SZV94JZSWoMpWE9C2EGHwnSR9RhNEjFcdTv+GQrJ8oaKPhw@mail.gmail.com>
Date: Sun, 13 Mar 2016 09:40:50 +0100
Message-ID: <CAAdgstQUm_1X0_uYFUQFSnLCvtcDcavPpaSBm8aGWiNVa_gHNg@mail.gmail.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Content-Type: multipart/alternative; boundary=001a114f8650111029052dea1f91
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/Pi7r2m_2xOMxKuKd4r1tPSH5PsU>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, Tero Kivinen <kivinen@iki.fi>
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 13 Mar 2016 08:40:54 -0000

Diego,

I think it's two different things.

1. Token is capable to identify a retries or a new transaction. (As Pascal
said.)
2. SF decides whether retry or not. (It's said in another thread)

They are not collisions.

Tengfei

On Fri, Mar 11, 2016 at 3:28 PM, Prof. Diego Dujovne <
diego.dujovne@mail.udp.cl> wrote:

> I agree with Xavi and Pascal on the use of the token:
>
> - To enable future concurrent requests
> - To enable retries.
>
> However, in another thread Tengfei proposed that the SF should
> take care of retries and 6P only respond to SFs as "OK" or "FAIL"
> transaction.
>
> Regards,
>
>                                  Diego
>
> 2016-03-09 14:27 GMT-03:00 Pascal Thubert (pthubert) <pthubert@cisco.com>om>:
>
>> Never seen a stupid question from you, Qin : )
>>
>>
>>
>> I agree with you actually.
>>
>>
>>
>> By “As it goes, it also enables to avoid the serialization of requests
>> but I agree that is a non goal today.” I meant that the child will
>> probably serialize hos requests, iow wait for one completion before it asks
>> for more. But with the token / seqnum we are open if one day we decide
>> otherwise…
>>
>>
>>
>> Take care,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* Qin Wang [mailto:qinwang6top@yahoo.com]
>> *Sent:* mercredi 9 mars 2016 16:48
>> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>
>> *Cc:* Tero Kivinen <kivinen@iki.fi>fi>; 6tisch@ietf.org; Prof. Diego
>> Dujovne <diego.dujovne@mail.udp.cl>cl>; Tengfei Chang <
>> tengfei.chang@gmail.com>
>> *Subject:* Re: [6tisch] 6P and Sf0 issue: Token to identify transactions
>> in 6P
>>
>>
>>
>> Pascal,
>>
>>
>>
>> I can see your point. Token is useful for Parent to distinguish Retry
>> from new Request by the Child.
>>
>>
>>
>> But, I have a stupid question: is it reasonable to allow the Child to ask
>> more cells before it gets Response to what it already asked?
>>
>>
>>
>> Thanks
>>
>> Qin
>>
>>
>>
>> On Wednesday, March 9, 2016 2:13 AM, Pascal Thubert (pthubert) <
>> pthubert@cisco.com> wrote:
>>
>>
>>
>> Hello Qin:
>>
>>
>>
>> Token 1 needs to be the same as token 2 when it is a retry. That's the
>> whole point.
>>
>>
>>
>> In your second case, say this is a child asking for a cell:
>>
>>
>>
>> - If this is a time out because the response from the parent was lost,
>> the parent should respond with the same cell as in the lost message.
>>
>>
>>
>> - But if the child got the response and still needs more bandwidth, then
>> the parent needs to allocate a second cell.
>>
>>
>>
>> How does the parent know?
>>
>>
>>
>> The main point of the sequence number is to be able to correlate the
>> retry.
>>
>>
>>
>> As it goes, it also enables to avoid the serialization of requests but I
>> agree that is a non goal today.
>>
>> Regards,
>>
>>
>>
>> Pascal
>>
>>
>> Le 8 mars 2016 à 22:10, Qin Wang <qinwang6top@yahoo.com> a écrit :
>>
>> Hi all,
>>
>>
>>
>> I'm not convinced that token is necessary yet. From the discussion in the
>> last WG meeting, we have agreed that the Token is used in the 6P message
>> exchange between neighbors. Based on the agreement, let's consider the two
>> following scenarios.
>>
>>
>>
>> (1) nodeA send ADD_Request(token=1) to nodeB, and not receive Response
>> from nodeB before Timeout. Then, nodeA send ADD_Request(token=2) to nodeB,
>> and receive Response(token=2) from nodeB.
>>
>>
>>
>> (2) nodeA send ADD_Request to nodeB, and not receive Response from nodeB
>> before Timeout. Then nodeA send ADD_Request to nodeB again, and receive
>> Response from nodeB.
>>
>>
>>
>> The question is if it is possible for nodeA to receive Response(token=1)
>> from nodeB later in (1). Since nodeA will send the second ADD_Request after
>> Timeout, I don't think it could happen. If I'm correct, I think the two
>> sequences function similarly. Thus, I wonder if it is necessary to have the
>> Token
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Thanks
>>
>> Qin
>>
>>
>>
>>
>>
>> On Tuesday, March 8, 2016 10:10 AM, Pascal Thubert (pthubert) <
>> pthubert@cisco.com> wrote:
>>
>>
>>
>> Oh yes, Tero,
>>
>> we agree on the bottom line and on your points.
>>
>> Cheers,
>>
>> Pascal
>>
>>
>> > -----Original Message-----
>> > From: Tero Kivinen [mailto:kivinen@iki.fi]
>> > Sent: mardi 8 mars 2016 15:50
>> > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
>> > Cc: Tengfei Chang <tengfei.chang@gmail.com>om>; 6tisch@ietf.org; Prof.
>> Diego
>> > Dujovne <diego.dujovne@mail.udp.cl>
>> > Subject: RE: [6tisch] 6P and Sf0 issue: Token to identify transactions
>> in 6P
>> >
>> > Pascal Thubert (pthubert) writes:
>> > > But this is another discussion entirely. It is about the transaction
>> > > that associates new timeslots to a bundle and why we need a
>> > > correlator, or transaction ID. I was explaining that if the parent
>> > > wait for the ack to allocate a slot that was negotiated, and there is
>> > > no flow after that, then if the ack is lost the child thinks the slot
>> > > is allocated and the parent does not. The child may start using it
>> > > wrongly.
>> >
>> > Which is why you should not use ACK for anything like that, but instead
>> use
>> > application level messages for that kind of things.
>> >
>> > > The point behind this is that if the transaction does not complete, it
>> > > must be retried from scratch with the same sequence, or it must time
>> > > out and roll back.
>> >
>> > Receiving or not receiving ACK should not cause transaction to complete
>> or
>> > not to complete, there must be some kind of application level message to
>> > indicate that it was successful if that information is needed in the
>> peers.
>> > --
>> > kivinen@iki.fi
>>
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>
>>
>>
>
>
>
> --
> 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
>