Subject: [core] WGLC comment for draft-ietf-core-coap-09: Resetting NONs

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 18 Apr 2012 09:21:43 +0200

Dear WG,

since Section 4.4.4 specifies that NON messages can be resetted.

However the specification gives no hint about how much time the
transmitter endpoint MUST be prepared to receive a RST message from
the recipient.

Should we specify a default value for this timeout?

Best,
Angelo

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Apr 2012 09:42:37 +0200

> since Section 4.4.4 specifies that NON messages can be resetted.

(i.e., replied to with a RST.)

> Should we specify a default value for this timeout?

Why would we need to specify anything here?

If the endpoint cares, it will have the state.
If it doesn't, the RST is just discarded.

(Note that we don't require endpoint to actually act on RSTs for NONs, this is strictly optional.)

(As a quality of implementation point, yes, this is another point were a time constant on the order of "2 MSL" ~ retransmission window is useful.)

Grüße, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 18 Apr 2012 09:54:25 +0200

> (As a quality of implementation point, yes, this is another point were a time constant on the order of "2 MSL" ~ retransmission window is useful.)

Assuming that the endpoint cares and wants to act upon RST, I would
like to have a default value defined for this.

Moreover, as in the related discussion about retransmission window, I
would like to have a smaller timeout for this, since in this situation
without retransmission the latency will be composed by network delay +
processing time, which I hope that we can suppose to be smaller than
256 seconds.

Do you think that defining such a default value is not useful?

Best,
Angelo

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Apr 2012 08:57:48 -0600

> (As a quality of implementation point, yes, this is another point were a time constant on the order of "2 MSL" ~ retransmission window is useful.)

Perhaps we should define a time constant with a value that represents the upper bound on what the Round Trip Time is allowed to be on the operational network. I'd suggest a default of 20 seconds.

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 18 Apr 2012 17:05:45 +0200

> Perhaps we should define a time constant with a value that represents the upper bound on what the Round Trip Time is allowed to be on the operational network. I'd suggest a default of 20 seconds.

Isn't that too much?

10 seconds of flight time seems unrealistic to me.

Best,
Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 18 Apr 2012 17:06:32 +0200

I had hoped something like 5-10 seconds of default value.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 06:44:45 -0600

Sure - I could live with 5 seconds. It won't work to access a device over a satellite link which is why I suggested a larger number. Carsten has pointed out in other threads this may be much longer so will be an interesting question. 

The important thing to me is that we have a well defined number. Whatever that number is, there will be some things that won't work but it gives applications and users something they know will work. 

It occurs to me that by defining the stop and wait retransmission time at 2 seconds, we are already assuming that the max round trip time is perhaps 2 seconds or perhaps 4 seconds but probably not hugely larger than that.

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 20 Apr 2012 16:05:11 +0200

On Fri, Apr 20, 2012 at 14:44, Cullen Jennings <[email-masked]> wrote:

> It occurs to me that by defining the stop and wait retransmission time at
> 2 seconds, we are already assuming that the max round trip time is perhaps
> 2 seconds or perhaps 4 seconds but probably not hugely larger than that.
>

Yes. However it should be noted that the spec defines that:

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.

*plus the expected maximum round trip time* which could be arbitrarily
high. How the endpoint emitting the CON knows this "maximum round trip
time" is not clear in the current writing.

Moreover in the case that this round trip time is very high, all the copies
of the messages are always transmitted and if loss rate is low a copy of
the ACK will be received for each with varying delay, thus this requires
deduplication at the recipient endpoint...

Best,
Angelo