Re: [6tsch] Confirmation Messages?

[Qin Wang <[e-mail]>]

I agree!

Qin


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

> 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 <[e-mail]> 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) <
>> [e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On
>>> Behalf Of *Xavier Vilajosana Guillen
>>> *Sent:* mercredi 4 septembre 2013 05:56
>>> *To:* Thomas Watteyne
>>> *Cc:* [e-mail]
>>> *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 <
>>> [e-mail]> 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 <
>>> [e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>>  ** **
>>>
>>> ** **
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>>
>>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>