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