Retransmission Issue

[cgundogan]

General CoAP proxy problem, but what to do when DoC server is a DNS proxy, response came not yet in but retransmission by DoC client was received

The CoAP spec does not really flesh out "corner cases" of certain proxy operations. In previous work, we addressed this retransmission issue in two different ways:

1. a proxy immediately sends an empty response, thereby stopping the retransmission of the DoC client. Any (later) response from the proxy SHOULD then be confirmable.
2. a proxy keeps request state and aggregates request retransmissions from downstream (similar to what NDN is doing). Therefore, no additional retransmissions propagate upstream.

[chrysn]

"General CoAP proxy problem" ... well, that's exactly what empty ACKs do and are designed for. Depending on the complexity of the proxy, the ACK can be sent right away, or a bit later depending on the retransmission characteristics. Working with CONs without keeping state isn't much of an option anyway.

[miri64]

Then this might not be a problem at all. Do we want to remove that TBD then?

[cgundogan]

While empty ACKs are designed for it, I think there is no proper explanation in the CoAP spec (w.r.t. proxy operation). Would probably be helpful to mention the empty ACK usage for this specific use case in this draft. Maybe as appendix on "best practices".

[chrysn]

The CoAP spec doesn't talk about it because it's nothing that is particular to a proxy. Reliable and unreliable transmission are things handled hop-by-hop, so as far as the proxy case is concerned, it is "just" a server that doesn't know precisely when it will have a response ready.

I do see value in pointing these things out as matters of best practice, possibly in this document (that is, unless there is a better suited document around, say "lightweight implementation guidance for CoAP proxies").

[miri64]

In the meantime I added a bullet point to the TBD list in the proxy-section on that.

[miri64]

I think after some considerations and in lieu of #18, I think @chrysn's comment is enough to close this issue.