Subject: Re: [6tsch] Confirmation Messages?

From: Thomas Watteyne <[email-masked]>
Date: Tue, 3 Sep 2013 18:59:14 -0700

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 3 Sep 2013 19:08:11 -0700

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

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 3 Sep 2013 20:55:37 -0700

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
<[email-masked]>wrote:

> On Tue, Sep 3, 2013 at 6:59 PM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Qin, all,
>>
>> 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.
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Sep 2013 13:59:39 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana Guillen
Sent: mercredi 4 septembre 2013 05:56
To: Thomas Watteyne
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

In this thread, we will continue the discussion about Confirmation message. Here is some background information.

Context: e.g.

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Qin Wang <[email-masked]>
Date: Thu, 5 Sep 2013 05:53:09 +0800

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) <
[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Xavier Vilajosana Guillen
> *Sent:* mercredi 4 septembre 2013 05:56
> *To:* Thomas Watteyne
> *Cc:* [email-masked]
> *Subject:* Re: [6tsch] Confirmation Messages?****
>
> ** **
>
> 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 <
> [email-masked]> wrote:****
>
> come in handy for the report flow for example.****
>
> ** **
>
> [email-masked]> wrote:****
>
> Qin, all,****
>
> ** **
>
> *[I hope you enjoyed the long week-end (here in the US) as much as I did!]
> *****
>
> ** **
>
> certainly would be better to have an end-to-end confirmation for others.**
> **
>
> ** **
>
> piggy-backing the response in the ACK for the query flow.****
>
> ** **
>
> retransmitting, etc, is already done for us.****
>
> ** **
>
> Thoughts?****
>
> ** **
>
> Thomas****
>
> ** **
>
> On Fri, Aug 30, 2013 at 10:47 AM, Qin Wang <[email-masked]> wrote:**
> **
>
>   Hi all,****
>
> ** **
>
> message. Here is some background information.****
>
> ** **
>
> Context: e.g.****
>
>     - node sends a report and want to know if the report is accepted., ***
> *
>
> ****
> 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)****
>
> ** **
>
> confirmation message.****
>
>     (1) Action Flow, needs a App-level confirmation, like Succ/Fail****
>
> packet corresponding to a specific query.****
>
> transport layer confirmation, which will give 6top more flexibility.****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Thanks****
>
> Qin****
>
>     ****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 4 Sep 2013 14:59:19 -0700

Qin,
I understand the distinction you are making. CoAP allows us to piggyback a
response. We still need to define what the answer is to a command in the
action flow, but we don't have to define a whole new set of packet types.
Does that work for you?
Thomas

On Wed, Sep 4, 2013 at 2:53 PM, Qin Wang <[email-masked]> wrote:

> 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
>
>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Xavier Vilajosana Guillen
>> *[I hope you enjoyed the long week-end (here in the US) as much as I
>> did!]*****
>>
>> ** **
>>
>> certainly would be better to have an end-to-end confirmation for others.*
>> ***
>>
>> ** **
>>
>> between piggy-backing the response in the ACK for the query flow.****
>>
>> ** **
>>
>> On Fri, Aug 30, 2013 at 10:47 AM, Qin Wang <[email-masked]> wrote:*
>> ***
>>
>>   Hi all,****
>>
>> ** **
>>
>>     - node sends a report and want to know if the report is accepted., **
>> **
>>

---

From: Qin Wang <[email-masked]>
Date: Thu, 5 Sep 2013 06:11:52 +0800

I agree!

Qin

On Thu, Sep 5, 2013 at 5:59 AM, Thomas Watteyne
<[email-masked]>wrote:

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