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

"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Fri, 11 March 2016 14:28 UTC

Return-Path: <diego.dujovne@mail.udp.cl>
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 BA5F912D754 for <6tisch@ietfa.amsl.com>; Fri, 11 Mar 2016 06:28:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.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 J7vEMSC0dQDh for <6tisch@ietfa.amsl.com>; Fri, 11 Mar 2016 06:28:04 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 8209112D5AC for <6tisch@ietf.org>; Fri, 11 Mar 2016 06:28:03 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id n186so21047222wmn.1 for <6tisch@ietf.org>; Fri, 11 Mar 2016 06:28:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=T6jUNoxd0MJhgOLucRtwIGlxPkFsxL3P1IdzQMtdB2s=; b=CRlki2HoINmVOKv37NI4akfE8DRxAeqT6yG8kyfl8Ri3rHAIh2RK298RMdbJn7ljOH RS0f5rM9asn+MsTGjemOwb2Dq+HKr7uba5M+Sg2nxAvD7h9mlToh2PlJRLSS90hdHj/F DQ9/XiTmMgLaIBpotJnL9E58rzY/+livg8wmKgBhGpQhAXLZYAKF2xZveSuLfgQXJhX2 QrFmxrcj48RAb0NEuFb1QT9ajUqhi712zmoxqL3uXCJbKVwyUB/KZbfq8yytIy1wwPiu zhz8an9p580UDqtevhlOdZ3yn9trM3qrbTzXCkFQX3ZZjMaY1yjTomznFjNOhudsO44B LBvw==
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=T6jUNoxd0MJhgOLucRtwIGlxPkFsxL3P1IdzQMtdB2s=; b=YScAFOVei/KzgmQE6tVa05XkrR5k38ViOzbBJGeDqojT8wa8WfhvqDz6CaTKEtnggX FntGdr0YNUkgo7syOnJr9Q80H9JWA62htgPhsBIAqv/mbRMC7BqaTRSKn2gIrz/YNDNx s3cb9IjpbSB1XnhvDRoYCkUM+ovR/eKNIICKqcz19A9iTO3JTahYVI71yiXTicERDL8T TUXUZUPUj9NcKjmHR1e6vJWVwIyses6Sbhx8upW08t4OI10RaMHbahs2yXgPV1jhv/ga HS6pma0rwNNDgkgvGlnSw+uAf1z5oz96MRd7LCIbfayZdQsmR8KsV39msd3PanWfmvcJ Qk5A==
X-Gm-Message-State: AD7BkJJrWO7PXmQhaEiH/zRrQsEElRLOe4QCyEpf3OPvV0x+AdO/96R4vmgHpVkmxuYy2QuVl/ml8bQY2QZvRg==
MIME-Version: 1.0
X-Received: by 10.194.2.169 with SMTP id 9mr10161765wjv.7.1457706481662; Fri, 11 Mar 2016 06:28:01 -0800 (PST)
Received: by 10.28.11.195 with HTTP; Fri, 11 Mar 2016 06:28:01 -0800 (PST)
In-Reply-To: <9d40e7f8ac2c486cb338deb6eeeb54f2@XCH-RCD-001.cisco.com>
References: <83F03D1D-FC7D-4502-80D5-9793DDE02DDF@cisco.com> <799700602.6733178.1457538467013.JavaMail.yahoo@mail.yahoo.com> <9d40e7f8ac2c486cb338deb6eeeb54f2@XCH-RCD-001.cisco.com>
Date: Fri, 11 Mar 2016 11:28:01 -0300
Message-ID: <CAH7SZV94JZSWoMpWE9C2EGHwnSR9RhNEjFcdTv+GQrJ8oaKPhw@mail.gmail.com>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b3a817006dfc4052dc6bda5
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/vTvjXapeuXZVaU-MhnuLTa3SkPg>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Tero Kivinen <kivinen@iki.fi>, Tengfei Chang <tengfei.chang@gmail.com>
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: Fri, 11 Mar 2016 14:28:06 -0000

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