Re: [6tsch] Confirmation Messages?

I agree too.

To be very clear:

We'll note that sometimes the confirmation of a request is indirect, like a request may trigger a flow and observing the flow is a confirmation that the request was received. Or there must be an app layer answer and observing that answer is a confirmation that the request went through. ISA100.11a transactions that really need an ack obey this model, and TCP level acks would just have been a waste of energy. That's a reason why we did not go for TCP but used UDP instead, using the app layer response as implicit acks, and deferring to the app layer whether and how to manage retries (based on RFC 2988).

With 6TiSCH, we also expect to use UDP (below CoAP) as a transport, so there is no real transport level ack -like a TCP ack- that would waste resources. For all I know we're probably well covered with the flows that CoAP enables, whether we want an acknowledgement or not, or whether the response is the acknowledgement that we are after.

Cheers,

Pascal

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
Sent: mercredi 4 septembre 2013 05:56
To: Thomas Watteyne
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] Confirmation Messages?

I completely agree with that. Having confirmations done by transport protocols simplifies our work and we do not need to re-invent the wheel.

so +1 for that.
X

On Tue, Sep 3, 2013 at 7:08 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> wrote:
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<mailto: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<mailto: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<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch