Re: [6tsch] Confirmation Messages?

Hi Thomas and all,

I want to make sure that you are not going to use Ack in transport layer to
replace the "Success/Fail" in Action flow, which is in App layer. Correct?
Usually, the meaning of status in App layer is different from that in
transport layer. For example, A Ack in CoAP just means a packet is sent to
the end node successfully. But the "Success" in App layer will mean the
action required is executed successfully.

Qin

On Wed, Sep 4, 2013 at 9:59 PM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

>  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> 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> 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****
>
>  ** **
>
> ** **
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>