Re: [6tsch] Confirmation Messages?

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 <qinwang@berkeley.edu> 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
>
>
> 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
>>
>>
>