Should definitely be of interest to implementers here. ---------- Forwarded message ---------- From: Jeroen Hoebeke <[email protected]> Date: Mon, Mar 26, 2012 at 5:19 PM Subject: [core] draft-ietf-core-coap-09: Separate response in a lossy context To: core WG <[email protected]>
Dear working group, During the plug test event, we noticed different behavior of implementations in case of separated responses in a lossy context. Case 1: - client sends CON request - ACK from server is lost - separate CON response from server to client - ACK from client to server Some implementations do not consider the CON response as an implicit acknowledgement and retransmit the CON request, causing unnecessary traffic. In section 4.1, the draft says: > > In particular, a CoAP request message may have elicited a > separate response, in which case it is clear to the requester that > only the ACK was lost and a retransmission of the request would serve > no purpose. This is only an implementation note. It would be better to state explicitly in section 4.1 of the draft: "The reception of a separate confirmable response before the acknowledgement should be considered as an implicit acknowledgement and should not result in a retransmission of the request in case the acknowledgment never arrives." Case 2: - client sends CON request - server sends ACK - server sends separate CON response - ACK from client to server is lost - server retransmits the CON response In several implementations, the reception of the ACK results in the removal of the context of the transaction (which makes sense for constrained devices). When the server retransmits the response, this results in a RST message. It would be useful to describe this behavior in section 4.1 (or section 4.4.4 as one of the cases where a RST is sent). For a CON request for which the ACK is lost, this behavior is well explained in section 4.1, but for the CON response for which the ACK is lost this is missing. "The reception of a retransmitted confirmable response due to the loss of the client's acknowledgment, may result in RST message in case the client removed the state information after sending the acknowledgment." Kind regards, Jeroen Hoebeke _______________________________________________ core mailing list [email protected] https://www.ietf.org/mailman/listinfo/core -- Best regards, Zhen _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
