Subject: [core] draft-ietf-core-coap-09: retransmission window

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 28 Mar 2012 11:00:32 +0200

Dear WG,

Section 4.1 tells:

   The same Message ID MUST NOT be re-used (per Message
   ID variable) within the potential retransmission window, calculated
   as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT -
   1) plus the expected maximum round trip time.

Question 1: Given that these parameters are not mandated by the standard,
does the spec assume that will be available some way to synchronize those
parameters across different implementations to correctly avoid reusing a
MID in the retransmission window?

Later on there is the following text:

   A recipient MUST be prepared to receive the same confirmable message

   (as indicated by the Message ID and additional address information of
   the corresponding end-point as described in Section 4.3
<http://tools.ietf.org/html/draft-ietf-core-coap-09#section-4.3>)
multiple
   times, for example, when its acknowledgement went missing or didn't
   reach the original sender before the first timeout.  The recipient

Question 2: Should be specified that "the recipient MUST be prepared to
receive the same confirmable message *within the potential retransmission
window*" as well?

Best,
Angelo

---

From: Likepeng <[email-masked]>
Date: Wed, 28 Mar 2012 09:11:44 +0000

> Question 1: Given that these parameters are not mandated by the standard, does the spec assume that will be available some way to synchronize those parameters across different implementations to correctly avoid reusing a MID in the retransmission window?

In our implementation, we choose arbitrary/random MIDs. I think it will be easy for the client to choose different MIDs in the retransmission window.

> Question 2: Should be specified that "the recipient MUST be prepared to receive the same confirmable message *within the potential retransmission window*" as well?

That will be helpful.

Kepeng

________________________________
发件人: [email-masked] [[email-masked]] 代表 Angelo P. Castellani [[email-masked]]
发送时间: 2012年3月28日 17:00
到: core
主题: [core] draft-ietf-core-coap-09: retransmission window

Dear WG,

Section 4.1 tells:

Question 1: Given that these parameters are not mandated by the standard, does the spec assume that will be available some way to synchronize those parameters across different implementations to correctly avoid reusing a MID in the retransmission window?

   (as indicated by the Message ID and additional address information of
   the corresponding end-point as described in Section 4.3<http://tools.ietf.org/html/draft-ietf-core-coap-09#section-4.3>) multiple
   times, for example, when its acknowledgement went missing or didn't
   reach the original sender before the first timeout.  The recipient

Question 2: Should be specified that "the recipient MUST be prepared to receive the same confirmable message *within the potential retransmission window*" as well?

Best,
Angelo

---

From: Markus Becker <[email-masked]>
Date: Wed, 28 Mar 2012 11:22:45 +0200

> MID in the retransmission window?

I was wondering about this as well, since clients and server cannot be assumed 
to be under the same ownership. SHOULD or MUST those settings (if not using 
the default setting) be exhibited under some profile like IPSO's? In the 
discovery phase than a conservative (large) setting for RESPONSE_TIMEOUT 
should be assumed?

Markus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Mar 2012 12:36:43 +0200

> Question 1: Given that these parameters are not mandated by the standard, does the spec assume that will be available some way to synchronize those parameters across different implementations to co…

We say this is out of scope in section 9.

	The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and MAX_RETRANSMIT may be configured to values specific to the application environment, however the configuration method is out of scope of this document. It is recommended that an application environment use consistent values for these parameters. 

I expect we will come up with a way to do this in the area of discovery and auto configuration.
Maybe we should add text about a default "potential retransmission window", e.g. 256 s.

> ) multiple

Now ticket #201.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Mar 2012 12:42:38 +0200

> Maybe we should add text about a default "potential retransmission window", e.g. 256 s.

Oh, and a little back-of-the-envelope exercise, too:

If we assume a value of 256 s, we can still send 256 messages per second from one endpoint to each other endpoint before the MIDs run out.
(You can use additional port numbers if that is not enough, but I think I'd switch to TCP when I need that level of throughput.)

The larger problem is of course keeping the state for all those MIDs around until the 256 s run out.  Please see

	http://tools.ietf.org/html/draft-bormann-lwig-guidance

for one discussion on how to do that.  Esko and I will certainly be happy to add your suggestions to this text!

One more observation: In many cases, a server can run stateless and completely eliminate the need to ever think about MIDs (except for echoing them back in ACK/RST).

Grüße, Carsten

---

From: Markus Becker <[email-masked]>
Date: Thu, 29 Mar 2012 09:41:34 +0200

> > does the spec assume that will be available some way to synchronize
> > those parameters across different implementations to correctly avoid
> > reusing a MID in the retransmission window?
> 

OK. But this might then be good to have somewhere else, e.g. IPSO profile.

> 	The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and
> MAX_RETRANSMIT may be configured to values specific to the application
> environment, however the configuration method is out of scope of this
> document. It is recommended that an application environment use consistent
> values for these parameters.
> 

Ignoring the retransmission window aspect of this and focussing on the 
discovery of the pure parameters, so that the client can adapt its behaviour 
to the server's setting, e.g. to RESPONSE_TIMEOUT. It is gonna be likely that 
the server has more knowledge about itself and the environment close to it, 
than a client far away, but the client should 'behave' to the server's 
constraints.

So it might make sense to add something along the following lines to e.g. the 
Device Function Set of the IPSO profile then.

CoAP protocol constant RESPONSE_TIMEOUT	
/dev/cpt
ipso:dev-cpt
core#p,core#rp
xsd:decimal

CoAP protocol constant RESPONSE_RANDOM_FACTOR
/dev/cpf
ipso:dev-cpf
core#p,core#rp
xsd:decimal

CoAP protocol constant MAX_RETRANSMIT
/dev/cpr
ipso:dev-cpr
core#p,core#rp
xsd:integer

> >    the corresponding end-point as described in
> > 
> > Section 4.3
> > ) multiple
> > 
> > receive the same confirmable message *within the potential
> > retransmission window*" as well?
> 
> Now ticket #201.
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core