Subject: [core] doubt regarding duplicate CON messages in CoAP

From: Hari Hara Sudhan R <[email-masked]>
Date: Thu, 2 Sep 2010 11:36:40 +0530

Hi all,

I have a doubt regarding duplicate CON messages in CoAP.

If we have a scenario as mentioned below how should the receiver respond.

Sender                Receiver

|     CON(TID = X)      |
|----------------------------->|
|                               |Receiver is processing the request.
|                               |
|      CON(TID = X)      |
|------------------------------>|
|                                |
|                                |

To discard the duplicate should the receiver maintain a list of
transaction IDs of confirmable
messages yet to be acknowledged?

I know the above scenario is unlikely but in constrained environment the
scenario is possible.

Does the specification mention anything for this scenario?

Thanks and Regards,
Hari Hara Sudhan R

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 Sep 2010 09:30:30 +0200

On Sep 2, 2010, at 08:06, Hari Hara Sudhan R wrote:

> To discard the duplicate

Well, the receiver should send an (another) ACK, not just ignore the CON.
(Otherwise, the initiator would never get a reply if the return packet is lost.)

> should the receiver maintain a list of

This is a question about implementation.
If the request is not idempotent, yes, the receiver needs to keep a list of TIDs to remove duplicate copies of the datagram or retransmissions.
If the request is idempotent, it is a matter of implementation convenience and performance whether this is done or whether each retransmission is processed and replied to from scratch.

Gruesse, Carsten

---

From: Hari Hara Sudhan R <[email-masked]>
Date: Thu, 2 Sep 2010 13:16:15 +0530

>(Otherwise, the initiator would never get a reply if the return packet is lost.)

If it is the same request that is getting retransmiited after a time-out.

The scenario I'm trying to explain is
"When receiver is processing a CON request sender times-out and
retransmit the same message again".

Thanks and Regards,
Hari Hara Sudhan R

---

From: [email-masked]
Date: Thu, 2 Sep 2010 11:57:03 +0200

Hi,

>If the request is not idempotent, yes, the receiver needs to keep a list
of TIDs to remove duplicate copies of the datagram or retransmissions.
>If the request is idempotent, it is a matter of implementation convenience
and performance whether this is done or whether each retransmission is
>processed and replied to from scratch.

How long the server shall retain the non idempotent requests ? If I'm right
, the server can't known if the client has received the ack so it shall
keep the transaction context during the retransmission window:
RESPONSE_TIMEOUT * (2 ^ MAX_RETRANSMIT - 1).

The sequence with timeout and retry is then:

Client             Server
       |                 |
       |    CON tid=47   |
       |    POST /foo    |
       +---------------->|  Process and store the result
       |                 |
       |    ACK tid=47   |
       |    200          |
timeout|  lost  X--------+
       |                 |
       |    CON tid=47   |
       |    POST /foo    |
  retry+---------------->|  Do not process and get the previous result

       |                 |
       |    ACK tid=47   |
       |    200          |
       |<----------------+
       |                 |
       |                 |  Free context with tid=47

Regards,
Matthieu VIAL

             Carsten Bormann                                               
             <[email-masked]>                                                
             Envoyé par :                                                A 
             core-bounces@ietf         Hari Hara Sudhan R                  
             .org                      <[email-masked]>      
                                                                        cc 
                                       [email-masked]                       
             02/09/2010 09:30                                        Objet 
                                       Re: [core] doubt regarding          
                                       duplicate CON messages in CoAP      

                                                                           

Well, the receiver should send an (another) ACK, not just ignore the CON.
(Otherwise, the initiator would never get a reply if the return packet is
lost.)

This is a question about implementation.
If the request is not idempotent, yes, the receiver needs to keep a list of
TIDs to remove duplicate copies of the datagram or retransmissions.
If the request is idempotent, it is a matter of implementation convenience
and performance whether this is done or whether each retransmission is
processed and replied to from scratch.

Gruesse, Carsten

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

---

From: Peter Bigot <[email-masked]>
Date: Thu, 2 Sep 2010 06:04:17 -0500

Interesting question.  I don't think we even have a SHOULD in the draft
specifying how rapidly the server must respond to a CON request, with either
a response or an ACK that converts it into an asynchronous request.  If it
takes two seconds to compute the response, and it's not made asynchronous
right away, confusion will result.

CON/ACK are part of the transport-layer of CoAP.  If the REST layer is
separated in an implementation following "best design practices", is it
possible that the part of the server that deals with this can't tell whether
the request is idempotent?  That's certainly true for proxies, isn't it?
Perhaps proxies must always immediately ack to convert requests to be
asynchronous.

Maybe we need a way for the server to detect retransmissions.  Recall that
UDP can deliver packets out of order, and could (especially in a wireless
mesh network with sleeping nodes) take quite a long time to get around to
doing so.  What we have now says the TID is specific to the (source)
endpoint.  It's supposed to change on each new transaction, but is not
required to be incremented by one.  I don't see a way for a destination to
infer the "freshness" of a packet by comparing its TID with the one last
received from the same source, since the TID is not associated with the
(source, destination) pair.

Peter

---

From: Zach Shelby <[email-masked]>
Date: Wed, 8 Sep 2010 13:43:00 +0300

On Sep 2, 2010, at 2:04 PM, Peter Bigot wrote:

> Maybe we need a way for the server to detect retransmissions.  Recall that UDP can deliver packets out of order, and could (especially in a wireless mesh network with sleeping nodes) take quite a long time to get around to doing so.  What we have now says the TID is specific to the (source) endpoint.  It's supposed to change on each new transaction, but is not required to be incremented by one.  I don't see a way for a destination to infer the "freshness" of a packet by comparing its TID with the one last received from the same source, since the TID is not associated with the (source, destination) pair.

This is something we have been thinking about especially for high capacity end-points (e.g. on M2M data collection server) dealing with large numbers of constrained end-points. There is nothing in the specification that would disallow a client from associating TID with each (source, destination) pair if it has the memory capacity for that. 

Zach 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297