Re: [core] Message ID sliding window

Dear Brian F., Frank W.,

you may want to take a look at this draft where sequential message IDs
are discussed:
http://tools.ietf.org/html/draft-castellani-core-coap-overhead-01
( and probably you want also to take a look at this one
http://tools.ietf.org/html/draft-castellani-core-transport-00 )

However this discussion seems currently out-of-scope for CoAP, which
as far as I know has already closed the "bigger"-part of the design of
its message-layer using different assumptions/features.

I am still working on something similar for different reasons..

Best,
Angelo

On Thu, Jun 16, 2011 at 23:55,  <fewilhoit@aep.com> wrote:
> Carsten,
>
> Sequential message IDs are not an application semantic.  They are a Layer 4
> semantic.  It appears to me that doing Layer 4 with random message IDs would
>  require the maintenance of more state, viz. a lookup table of message IDs
> that have not yet been ACKed or timed out.  Again, to Brian's point, clients
> do not gain anything from the privilege of randomizing message IDs .  When I
> read the spec, I silently assumed that message IDs would be sequential and
> per-connection.
>
> Out-of-order messages and dropped messages are going to be a constant
> problem on RF mesh networks.
>
> It is a fine idea to supplant TCP in a semi-connected environment, but you
> have to get to Layer 4 somehow.
>
> thx
>
> Frank Wilhoit
> Enterprise Information Architect
> Enterprise Architecture and Strategy
> American Electric Power
> Direct Dial 614.716.3878
> Audinet 8.200.3878
>
> Scraping the bottom of a different barrel, since 1958.
>
>
>
>
> From:        Carsten Bormann <cabo@tzi.org>
> To:        Brian Frank <brian.tridium@gmail.com>
> Cc:        core <core@ietf.org>
> Date:        06/16/2011 05:36 PM
> Subject:        Re: [core] Message ID sliding window
> Sent by:        core-bounces@ietf.org
> ________________________________
>
>
> Brian,
>
> You lost me.
>
>> - today a server is required to allocate a buffer of X message IDs per
>> client.
>
> Why/what for?
> Most servers are completely stateless, they don't need to allocate anything.
> Where they do need to (non-idempotent methods like POST), they also usually
> need to store responses, so there is little savings in just being able to
> compress message-IDs.
>
> Can you explain the usage scenario some more where this would make a
> difference?
>
>> - serial Message IDs make it easy to detect out-of-order messages (if the
>> application level needs to know)
>
> Danger, Will Robinson.  Are you suggesting that we start giving application
> semantics to message-IDs?
> That would be serious conflation.
>
> (Yes, we do have an out-of-order detection problem, which is addressed in
> -observe.
> If there were a way to simplify this with message IDs, that might be
> interesting -- but I think the current way is already rather simple as it
> is.)
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>