Subject: Re: [core] Comments on draft-ietf-core-observe-10

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Oct 2013 22:30:09 +0200

On Sep 30, 2013, at 18:06, "Peter A. Bigot" <[email-masked]> wrote:

> My last comment: please make clear that when the steps in observe 4.5 occur the message ID is (or is not) expected to be one of the things that changes when the new transmission starts with the retransmission state left over from the superseded transmission.  That clarity is absolutely lacking in the current draft for anybody who hasn't been actively involved in observe over the last three years.

The message ID is used for duplicate detection, so if you have new data that you want a receiver to actually receive in addition to the old data, you have to send the new data with a new message ID.  (Note that the message ID is different from the Observe Option value, which is also a sequence number.)

I think some of the confusion comes from the fact that a simple canceling of a transmission sequence in progress is dangerous, if it also simply clears the binary exponential backoff (BEBO) counter.  This means that a server could send unacknowledged notifications at a high rate if the resource changes fast enough -- a recipe for congestion overload.

So one way to keep the request/response/notify layer separate from the message layer is to implement cancel in such a way that the BEBO counter is saved for the peer.  A server that has a new value for the resource can then simply cancel the transmission of the old one; if that was never acknowledged, the new resource value will be transmitted at the back-off rate.  (An optimization where incoming acknowledgements for canceled transmissions are still handled is left as an exercise for the reader :-).

Grüße, Carsten

---

From: "Peter A. Bigot" <[email-masked]>
Date: Fri, 04 Oct 2013 14:39:36 -0500

On 10/02/2013 03:30 PM, Carsten Bormann wrote:
>> My last comment: please make clear that when the steps in observe
>> 4.5 occur the message ID is (or is not) expected to be one of the
>> things that changes when the new transmission starts with the
>> retransmission state left over from the superseded transmission.
>> That clarity is absolutely lacking in the current draft for anybody
>> who hasn't been actively involved in observe over the last three
>> years.
>
> The message ID is used for duplicate detection, so if you have new
> data that you want a receiver to actually receive in addition to the
> old data, you have to send the new data with a new message ID.  (Note
> that the message ID is different from the Observe Option value, which
> is also a sequence number.)

Yes, as I've made progress in the new CoAPy that was the obvious right 
choice though it had not been clear in the description or the discussion.

>
> I think some of the confusion comes from the fact that a simple
> canceling of a transmission sequence in progress is dangerous, if it
> also simply clears the binary exponential backoff (BEBO) counter.
> This means that a server could send unacknowledged notifications at a
> high rate if the resource changes fast enough -- a recipe for
> congestion overload.

Yes; though this requirement is independent of observe's technique of 
superseding a partially-completed transmission with a new message. 
coap-18 4.2 permits a server to cancel remaining retransmissions of a 
confirmable message.  I believe the intent of 4.2 and 4.7 is that the 
cancelled message remains technically outstanding and thus blocks 
further transmissions as constrained by NSTART unless there is evidence 
that the destination endpoint received the message.

>
> So one way to keep the request/response/notify layer separate from
> the message layer is to implement cancel in such a way that the BEBO
> counter is saved for the peer.  A server that has a new value for the
> resource can then simply cancel the transmission of the old one; if
> that was never acknowledged, the new resource value will be
> transmitted at the back-off rate.

And this I think is still a mistake.  For observe, where we don't really 
care if the message gets through, I suppose you can do this as an 
optimization.  But what happens if the new message uses the last two of 
five total transmissions, and isn't acknowledged?  Is something allowed 
to detect this, and use part of the next BEBO cycle to give that message 
the total number of transmissions it warrants?

What if the next message for the destination endpoint isn't even an 
observe notification, but another confirmable message queued for the 
same endpoint before the resource changed and observe chose to supersede 
the current one?

Madness lies in this direction.

> (An optimization where incoming
> acknowledgements for canceled transmissions are still handled is left
> as an exercise for the reader :-).

Well, you have to handle that anyway, so it's not a big deal.

Peter