Re: [6tsch] Confirmation Messages?

Thomas Watteyne <watteyne@eecs.berkeley.edu> Wed, 04 September 2013 02:08 UTC

Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A5721E8128 for <6tsch@ietfa.amsl.com>; Tue, 3 Sep 2013 19:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vOpo3ZE+Ddw for <6tsch@ietfa.amsl.com>; Tue, 3 Sep 2013 19:08:31 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B6E9B21E811A for <6tsch@ietf.org>; Tue, 3 Sep 2013 19:08:31 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id lb1so7190389pab.40 for <6tsch@ietf.org>; Tue, 03 Sep 2013 19:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=vO6uYRsXnF18tCMN31G4vIWgovEmxVhD/R004hfx5Zo=; b=QtFi8CBHt3zRQXylqOOfZWPzR8hxDENHCmXTPqc8HKPq1gZ7rnPru+lXGuTYxSUDLn gICNDW4hZbD4dm1s8Zcnp/XIZ/RxAvmWCnKoXGe/2z2yPPaTj8cXhdT1JQIXhzq40Y85 6Khfkt+GX95J1m4M6F8DX7gUytjSy/dZI4J5lS/k3CbNEZ9S9HF8XfwqwciUNP6nyCT7 g2cA+knYF374yYluP8OdFWUtgzSlS3ukfhbTe6An8/0tsCoWCzIh04QnIW0udUpN8Yho GyE8PKlUa1++1qN/6vT6LJ9Y4+gq3VX89Ib9XKFsnFlVoYci8feUzIiCuEkX5EGX3XPi zyyg==
X-Received: by 10.66.142.107 with SMTP id rv11mr645520pab.17.1378260511455; Tue, 03 Sep 2013 19:08:31 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Tue, 3 Sep 2013 19:08:11 -0700 (PDT)
In-Reply-To: <CADJ9OA-EJSobC+i-nhRc-OgS_vH2xcZn5G0r1zm6h0fkTneL7w@mail.gmail.com>
References: <CAAzoce768TLENEYM34OEasDdTTHWTN4DRmEaOOZHOf_gBR6smQ@mail.gmail.com> <CADJ9OA-EJSobC+i-nhRc-OgS_vH2xcZn5G0r1zm6h0fkTneL7w@mail.gmail.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Tue, 03 Sep 2013 19:08:11 -0700
X-Google-Sender-Auth: Z5oxtw3x-5henxg98aeBaZ9jHAM
Message-ID: <CADJ9OA-L2TH=3t5DNWpRgLxw=yE1Po-Hhj+K8qFPpN8Af22+AA@mail.gmail.com>
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary="001a11331e463181d804e585487f"
Subject: Re: [6tsch] Confirmation Messages?
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
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" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2013 02:08:32 -0000

One last thought: http://tools.ietf.org/html/draft-ietf-core-observe-09 might
come in handy for the report flow for example.


On Tue, Sep 3, 2013 at 6:59 PM, Thomas Watteyne
<watteyne@eecs.berkeley.edu>wrote:

> Qin, all,
>
> *[I hope you enjoyed the long week-end (here in the US) as much as I did!]
> *
>
> As Maria Rita pointed out during the call on Friday, let's try to make
> absolutely sure we don't over-complicate things. I believe I agree with the
> fact that different flows might have different requirements. Link-layer
> ACKs can guarantee a level of reliability acceptable to some flows, but it
> certainly would be better to have an end-to-end confirmation for others.
>
> My vote would go for using the underlying "transport" mechanism to provide
> us with some confirmation capabilities. If we take the example of CoAP, we
> could say that action and query flows MUST use confirmable messages, while
> report and event MAY. CoAP would also allow us to switch between
> piggy-backing the response in the ACK for the query flow.
>
> The advantage is that we do not have to reinvent this "transport"
> mechanism. The mechanism for triggering an ACK, timing out and
> retransmitting, etc, is already done for us.
>
> Thoughts?
>
> Thomas
>
>
> On Fri, Aug 30, 2013 at 10:47 AM, Qin Wang <qinwang@berkeley.edu> wrote:
>
>> Hi all,
>>
>> In this thread, we will continue the discussion about Confirmation
>> message. Here is some background information.
>>
>> Context: e.g.
>>     - node sends a report and want to know if the report is accepted.,
>>     - ME sends a action request and want to know if/when the action taken.
>> Options:
>>    (1) Nothing
>>    (2) Rely on transport mechanism (e.g. confirmable CoAP message)
>>    (3) App-level ACK type
>>    (4) Use different flow (i.e. action flow)
>>
>> IMHO, different control flow may have different requirement for
>> confirmation message.
>>     (1) Action Flow, needs a App-level confirmation, like Succ/Fail
>>     (2) Query Flow, automatically has the confirmation, i.e. the message
>> packet corresponding to a specific query.
>>     (3) Report Flow and Event Flow, option (1)-(3) are OK, but I prefer
>> option (1) and (3), i.e. the confirmation message is an option, but if a
>> confirmation message is needed, it should be App-level Ack, instead of
>> transport layer confirmation, which will give 6top more flexibility.
>>
>> What do you think?
>>
>> Thanks
>>  Qin
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>