On Fri, Nov 25, 2005 at 01:26:20PM -0800, Andy Bierman wrote:
Application-Level ACKs
It is not clear what a sender would do differently even
if it knew the receiver did not understand the message.
Without specific features in the protocol which would
need app-level ACKs (such as data model version negotiation),
the cost and complexity of this feature cannot be justified.
I think that we require Netconf Notification ACKs, and they can be
optional as was done in SNMPv3 (i.e.: unACKed traps, ACKed informs).
They are required for cases where the sender needs to know if the
information was successful transmitted and may decide to retransmit at a
later time.
I'm not sure we are all clear on the semantics here.
What I think we mean by application-layer ACK
is the receiver understood the message. TCP lets
us know the receiver got the message.
I don't see how retransmitting at a later time will
help the receiver understand the message (delivered as sent)
any better, unless the reason the message was garbled is
an intermittent bug in the sender. I don't think we need to
worry about this case in the protocol. Because if this isn't the case, then
the exact same error condition will occur no matter how
many times the sender retries.
My understanding is that a netconf protocol does not exist in
isolation and that most events that trigger netconf notifications will
originate in other pieces of software. For some pieces of software,
"shout and forget" is all what is needed. Other applications may want
to know whether they were heard so they can for example flush entries
in notification logs (as Randy mentioned).
If we don't provide application layer acks for those apps who need it,
then these apps will end up using TCP acks as the only approximation
for the indication that everything went fine. Such a best guess may
work, but it surely is not what I would call a robust solution (but
who cares about this these days).