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

[Kevin Hawkins]

> -----Original Message-----
> From: Patrick Lidstone [mailto:<a
href="/group/xAP_developer/post?postID=OS9TlABp4SeO-NtVz0QLI2QK0PhfiJrPHiuNkCY_kun-c9_8I0lQSBN4yqne4L4QnGVJMGBAIcnFLQ">patrick@l...</a>]
> Sent: 17 June 2003 14:02
> > 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.
>
> This could be dodgy ground. I would argue that a checksum failure is
> grounds for a requesting a retry, but that an otherwise malformed
> message (unexpected content etc) is not - since this can't be
> corrected by a simple retransmission, so it should simply be
> discarded by the recipient.
>
> Somehow we need to guard against a flood of retry requests from
> multiple recipients...

We meant the same here - by a corrupted message I meant that the address
info had got through but the data content hadn't, hard to see how this
might
happen unless we error checked the header separate to the body - perhaps it
could happen if we had chained messages - anyway we agree - malformed
packets should not generally be nacked

>
> > 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.
>
> Yes, I think this needs more thought. A unique sequence number count
> is probably maintained for each set of unique (UID, target string)?
> It is only a couple of bytes, so it's not too burdensome.

Makes me thing a little about the targetting based on UID topic again where
we could incorporate the target UID and the sequence number into one field
-
just thinking aloud here - I still don't see a major benefit to this way of
doing it (target uid).

>
> > 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.
>
> I don't think we want (or need) to be able to turn acking on/off. I
> can't think of a scenario in which this would be useful, and I can
> see all sorts of potential difficulties arising if either the
"on"
> or "off" message itself gets lost.

My thought were around the wildcarded target route - where we already new
most devices had got the data and wanted to stop them acknowledging it
again. Or perhaps where we were sending a non targeted message but we
wanted
to ensure that a critical device received it (perhaps a cache or a
controller) - setting an ACK mode for all traffic - realising the xtra
traffic issues - or perhaps an ACK for all packets from this specific
source.
Which sort of leads on to a retry type problem - if you did ask say all you
relays to pulse on for 1 sec but one device missed it - we may need a way
of
resending it such that devices that already had done this didn't do it
again. A sort of retry/transaction identifier. Maybe we could engage
sequencing between two devices for the life of a transaction or something.

Start transaction 0000
Tx 0001
Rx 0002
Tx 0003
Rx 0004
Tx 0005 -lost
TX 0005a -lost
TX 0005b
Rx 0006
End transaction 0007
>
> >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.
>
> Max retry count is a good idea. This could also be time based.
>
> > 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
?
>
> I think including them in the HB is quite elegant, it doesn't raise
> the bar too high. There's no reason why they shouldn't be duplicated
> in a status request/response, but I can't see smaller devices
> bothering to implement the ability to generate a status request,
> whereas parsing the HB is trivial.

I tend to agree this may be best in the HB - maybe as a body part even ??
In
one of the other threads I was proposing that all devices (capable of
transmitting &amp; receiving xAP messages MUST implement a minimal
status
response) - ie making this mandatory when they are specifically targeted.
>
> > Do we need any form of priority mechanism in xAP at the
> protocol
> > layer ??
>
> This is an interesting idea! But what does priority actually mean?
> There shouldn't typically be queues of messages sitting around, so
> there isn't any means for a message to "overtake" another.
Similarly,
> the actual processing of a message shouldn't take very long, so
> interrupting the current messages doesn't seem to make a lot of sense?

It was just a thought - it has some application where packets are
bridged/routed from a higher bandwidth to a lower bandwidth network - and
possibly also in determining which data may be discarded if filtering is
applied. Some network actions (housekeeping / config) for example might say
put a device into a state where it will only respond to level 1 data -
obtaining a devices total attention and avoiding a device getting
sidetracked by other broadcast data. Overall no strong view at this stage
on
this topic.

K