RE: Re: Topic 4: Point to point acknowledgement in xAP messages

[Kevin Hawkins]

A poor solution - nah - what I did was to launch this thread (4) on 10th
June with a melange of ideas around what we are trying to achieve with such
a system - picking up on the ability to handle bindings that allowed pairs
of devices to become able to ensure packet integrity paths between them in
bohtth one to one, one to many and many to many scenarios. It also
mentioned the possible need to mandate support for target=*.*.> or a
target
message that exactly matched the destinations address.

The proposal you made below was the basis for this & I think is a
great
solution to most of these issues - just trying to get input from a load of
people on this.

My 2p worth is...

tm is a little cryptic in a message header where readable is the
norm, I prefer ACK (or Acknowledge or Reply)

I like the ability to both positive acknowledge and negative
acknowledge. As I see it a device should negative acknowledge when it
determines it has missed a message that was meant for itself - either
because it sees a targeted message at itself where a previously sequenced
message is missing or it manages to get the addressing info but the payload
is corrupted (unlikely). Are there other situations - eg it doesn't see a
message it expected perhaps.

Re the sequencing - that obviously works but requires a device that
wants to use targeting to maintain a separate sequence number for each
device - adding to overhead - useful though I think. What happens though in
a target=UKUSA.thermostat.> scenario - I assume that targets will have
to be
single matches to support specific sequencing.
At the point acknowledges are requested in a one to many scenario
then the various receivers will have to start to pay attention to the
sequence numbers - we may need a 'pay attention from now on' type message
to
enable acknowledges ( or neg acknowledges) in a one to many scenario. Do we
need to have an ability to turn negative acknowledges off on specific
devices remotely. (Negative acks could appear for all messages, non
targeted)

I think it would be nice to tidy up the retry mechanism in a
standard way - rather than leave it to individual implementation in the
application layer. That way all our devices will interoperate nicely - we
also probably need to discuss a max number of retries scenario when a
device
attempts communication but is unable to succeed for whatever reason and
gives up - but this may be supportable at an application layer.

A device can as you say in it's heartbeat indicate whether it can
support positive/negative acks and sequencing - this is the logical place
for it - but- thinking ahead are there a load of such capabilities that we
may need to be able to report - for example support for targeting - support
for wildcarding - depth of addressing supported etc - should all these sit
in a xAP.capabilities 'status' type response - that way they don't clutter
the network up by being (redundantly) included in every heartbeat ? These
features acks/seq may be so fundamental they belong in every heartbeat
though.

Do we need any form of priority mechanism in xAP at the protocol
layer ??

Thoughts ?

Kevin


> -----Original Message-----
> From: Patrick Lidstone [mailto:<a
href="/group/xAP_developer/post?postID=GnWeVqCLFM-J1bMqEqaXsD9OILgAkoX4GYXs2vsfZ_Z9joLFJv1j-IicFQZPt541cQmkA8cIE5WaPHdL1WwA">patrick@l...</a>]
> Sent: 17 June 2003 09:44
> To: <a
href="/group/xAP_developer/post?postID=coShv0grYG5-UEDP8Cnn459IprNBrfv6FT9HGDWTA_6yoYPJ-Gx4x6kdJvFSWNLb6JpTK5835OdgwEWtzVZGIL7wVA">xAP_developer@xxxxxxx</a>
> Subject: [xAP_developer] Re: Topic 4: Point to point acknowledgement
in
> xAP messages
>
> Here's a repost of my earlier thoughts on acks from a few weeks back.
> Not sure if they have been discounted as a poor solution, or if they
> just got lost in the noise.
>
> - 3 scenarios, all ack and sequence related.
>
> Negative Ack:
> Receiver benefits from detecting the loss of a message, and can re-
> request or take action as appropriate, but doesn't generate any
> network traffic in the default case where everything works ok.
>
> Positive Ack:
> Receiver acknowledges receipt of every message explicitly. Can be
> useful for flow control (next message isn't sent until timeout/ack is
> received). Guarantees that the sender knows an action was performed.
>
> Sequencing:
> Receiver is able to concatenate sequenced messages to form a message
> that is bigger than the underlying transport can handle. Might be
> useful one day.
>
>
> Possible mechanism:
>
> xap-header
> {
> ...
> tm=+ -OR- tm=- -OR- tm is omitted
> seq=nnn
> ...
> }
>
> where tm is transport mode, and + is positive ack and - is negative
> ack and seq is sequence.
>
> Sender increments sequence according to these rules:
> - If the message is a targeted message, sequence increments for that
> specific target
> - If message is source addressed, sequence increments for that source
>
> The receiver can track sequence numbers for a source that they are
> interested in by storing UID and sequence number. (UID is proving
> invaluable...) They would only need to do that in the negative ack or
> concatenation scenario.
>
> A receiver indicates supported transport modes by including:
>
> xap-hbeat
> {
> ...
> tm=+-
> ...
> }
>
> in their heartbeat.
>
> Fully backwards compatible - any of the tm / seq fields may be
> omitted, and interoperability should be seamless. Adds a lot of
> flexibility (too much?) for very little overhead.
>
> Note that recovery action on loss of sequence / retransmission
> requests are left at the discretion of the application layer. This
> makes the whole scheme very small-device friendly.
>
> Patrick
>
>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Looking for the latest Free IT White Papers?
> Visit SearchNetworking.com to access over 500 white papers.
> Get instant access at SearchNetworking.com Today
> <a href="http://us.click.yahoo.com/KfiLPA/OLNGAA/yigFAA/dpFolB/TM";>http://us.click.yahoo.com/KfiLPA/OLNGAA/yigFAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=MCI2e4ALRorP2FRYcdedxtvugHvt02AXt-wSv18rZMMOl9OVNIaxEDEIcFw4uY7pCKxtRp3O0Vxoxg4UCfPMiehwWIG0MT1luKxGoCw4Ew">xAP_developer-unsubscribe@xxxxxxx</a>
>
>
>
> Your use of Yahoo! Groups is subject to
> <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a>