Re: [6tsch] Confirmation Messages?

Thomas Watteyne <watteyne@eecs.berkeley.edu> Wed, 04 September 2013 01:59 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 19C0221E811D for <6tsch@ietfa.amsl.com>; Tue, 3 Sep 2013 18:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.085, 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 KfYMKjGEL6T4 for <6tsch@ietfa.amsl.com>; Tue, 3 Sep 2013 18:59:46 -0700 (PDT)
Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BF5FE21E811A for <6tsch@ietf.org>; Tue, 3 Sep 2013 18:59:38 -0700 (PDT)
Received: by mail-pb0-f50.google.com with SMTP id uo5so6677218pbc.23 for <6tsch@ietf.org>; Tue, 03 Sep 2013 18:59:36 -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=2evUn4mc+VXGjoX4TvQpf6n6dhFn6tOQn4UyRSQqHTg=; b=fYwUaT3U5EDgRJ8YNs9qRFo1o3FxA9nlGquFVu4dWpv/a1sZVSL0IeXh4xgbpvePGJ CX+LI/IqxTM+vv+BA5QOGce0RFAFGVfq/EJ+P4mHYNCFk/ErzSSJtkV1qecBLF4wNJqI 2qyT0fYYfSxy4ZbokbJ//fs7l50/nGlDRPZM0rXAycHQJDEniw6yNvSXSSBRx1vpQqMJ +vJPk9RdFm5cuMOfl7kVbTU0qzOsvn6oEQVboG5JFBOZ7VSPhqBHmSZ7x4HTVtowUxfH W/exUQw0LpPfNrqbnAc8ojrCsFPZzrgz6Ots4guup7gnBXEoha5DlDQ2Qq0o7lnXdRoZ GS/g==
X-Received: by 10.66.120.145 with SMTP id lc17mr419077pab.182.1378259975005; Tue, 03 Sep 2013 18:59:35 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Tue, 3 Sep 2013 18:59:14 -0700 (PDT)
In-Reply-To: <CAAzoce768TLENEYM34OEasDdTTHWTN4DRmEaOOZHOf_gBR6smQ@mail.gmail.com>
References: <CAAzoce768TLENEYM34OEasDdTTHWTN4DRmEaOOZHOf_gBR6smQ@mail.gmail.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Tue, 03 Sep 2013 18:59:14 -0700
X-Google-Sender-Auth: 6_sfP5zf3JGsUo5Q9oHBcNuyQdg
Message-ID: <CADJ9OA-EJSobC+i-nhRc-OgS_vH2xcZn5G0r1zm6h0fkTneL7w@mail.gmail.com>
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary="e89a8ffbaca137ebb204e585284e"
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 01:59:47 -0000

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