Subject: Re: [core] Protocol Constants section of coap-08

From: August Betzler <[email-masked]>
Date: Mon, 20 Feb 2012 15:08:11 +0100

Hi,

I understand that small initial backoffs may lead to problems in your
networks. Could you give us a short statement, about why you are
experiencing "large" delays? What I'm actually interested in is the size
and composition of your networks or maybe even the average number of hops
for data transmissions. Is the large delay/RTT you observe a consequence of
large internal processing times or maybe due to congestion? I'm asking,
because we are also interested in finding an adequate inital
RESPONSE_TIMEOUT for our (currently rather small) networks. We are not
quite shure, if using a fix interval as initial backoff is a good solution
though. As it has already been stated, the "optimal" value depends on the
network size, it's architecture and the operations that are carried out, so
I think it will be difficult to find a initial timeout that fits most of
the networks and applications.

Also, with the currently proposed values, the margins of the backoff
interval get quite large after a few retries (3 or 4, it does not matter).
This may result in long periods of time, during which message buffers are
reserved and therefore not available to other transmissions. Especially for
constrained devices with low memory capacity this may represent a problem,
in particular, when several CoAP operations have to be executed in short
periods of time over lossy or strongly congestioned paths (so packets may
actually get lost or suffer from large delays). Capping the number of
retries may be one solution to avoid exaggerated timeouts, even though this
could reduce the probabilities for a successful transmission.

August

> Tom,
>
> Agreeing with you on all points. The intention has been that those constants are configurable. Could you propose some new text?
>
> Regarding RESPONSE_TIMEOUT, I would like to find a default value that works for the majority of LoWPANs at least. Don't see a problem in increasing that somewhat, for example to 3-4 seconds. With a longer starting timeout, it may make sense to reduce MAX_RETRANSMIT to 3.
>
> Zach
>
> On Feb 18, 2012, at 8:27 PM, Thomas Herbst wrote:
>
> > Trying to come up with a better way to deal with the protocol constants
> > section.
> >
> > Obvious first edit is that all three values - Timeout, random factor and
> > max retransmits should be configurable.
> >
> > Next step might be to state that these are configurable, but the
> > configuration is out of scope of this document.
> >
> > Deployment guidance could be that the numbers should be constant for any
> > given network, though I can think of several cases where I might have
> > different constants for different node types, but that is me playing with
> > my own rope.
> >
> > On the specific numbers, 2 seconds is way too short of a default for our
> > networks, but I understand having everyone use our constants for their
> > smaller networks may make the smaller networks slower than necessary.
> >
> > Someone putting an unconfigured device on a network should work.  Best
> > case would be the unconfigured device would work efficiently.
> >
> >
> >
> > Tom
> > ------------------------------------------
> >
> > 9. Protocol Constants
> > This section defines the relevant protocol constants defined in this
> > document:
> > RESPONSE_TIMEOUT 2 seconds
> > RESPONSE_RANDOM_FACTOR 1.5
> > MAX_RETRANSMIT 4
> > Future specifications are expected that will allow implementations to use
> > other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT
> > variable MAY be configured with a different value for special environments
> > that exhibit very short or very long RTTs.
> >
> > _______________________________________________
> > core mailing list
> > core at ietf.org
> > https://www.ietf.org/mailman/listinfo/core
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.http://www.sensinode.comhttp://zachshelby.org  - My blog "On the Internet of Things"http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Feb 2012 16:18:17 +0100

On Feb 20, 2012, at 15:08, August Betzler wrote:

> Capping the number of retries may be one solution to avoid exaggerated timeouts, even though this could reduce the probabilities for a successful transmission.

Indeed.

One way of increasing the minimum wait time without increasing the maximum is clamping up the wait.

So, right now we have

2	4	8	16	32

If we naively increase this to 3, we get

3	6	12	24	48

Instead, we could go to a min of 3 this way:

3	4	8	16	32

or (increasing the min to 5):

5	5	8	16	32

(You could also clamp while keeping the total, as in
3	3	8	16	32
and
5	5	5	15	32
and
10	10	10	10	22
and so on. Algorithms are left as an exercise for the reader :-)

Beyond this little tweak, I agree that the protocol constants are tunables.

Going significantly below the values that are equivalent to those characteristic of TCP behavior will jeopardize TCP-friendliness, though.
Also, you just may not know how well the network at the other end of the conversation is working, so tuning for your local network may not help you very much.

If you have the space, keep state from previous conversations with the same place, and use something like EWMA to evolve that state.

Grüße, Carsten

---

From: Thomas Herbst <[email-masked]>
Date: Wed, 22 Feb 2012 09:44:10 -0800

Our largest network has over 5 million devices deployed, with several thousands aggregated into each access point. The average number of hops is fairly low, but geography (going around a hill or other obstruction) can result a longer tail.  We need to design to those edge cases.

After thinking about this some more, perhaps the most expedient way forward to just to specific that all three parameters are configurable and offer a reasonable default.  We are okay with that default being fairly short and devices connecting to our network changing from the defaults.  Some adaptive,  negotiated or full defined configuration method would be unneeded complexity in the base spec.

Existing Text :

> Future specifications are expected that will allow implementations to use> other sources for initializing RESPONSE_TIMEOUT. The RESPONSE_TIMEOUT

Suggested Text :

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

tom

From: August Betzler <[email-masked]<mailto:[email-masked]>>
Date: Mon, 20 Feb 2012 06:08:11 -0800
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] Protocol Constants section of coap-08

Hi,

I understand that small initial backoffs may lead to problems in your networks. Could you give us a short statement, about why you are experiencing "large" delays? What I'm actually interested in is the size and composition of your networks or maybe even the average number of hops for data transmissions. Is the large delay/RTT you observe a consequence of large internal processing times or maybe due to congestion? I'm asking, because we are also interested in finding an adequate inital RESPONSE_TIMEOUT for our (currently rather small) networks. We are not quite shure, if using a fix interval as initial backoff is a good solution though. As it has already been stated, the "optimal" value depends on the network size, it's architecture and the operations that are carried out, so I think it will be difficult to find a initial timeout that fits most of the networks and applications.

Also, with the currently proposed values, the margins of the backoff interval get quite large after a few retries (3 or 4, it does not matter). This may result in long periods of time, during which message buffers are reserved and therefore not available to other transmissions. Especially for constrained devices with low memory capacity this may represent a problem, in particular, when several CoAP operations have to be executed in short periods of time over lossy or strongly congestioned paths (so packets may actually get lost or suffer from large delays). Capping the number of retries may be one solution to avoid exaggerated timeouts, even though this could reduce the probabilities for a successful transmission.

August

Tom,

Zach

On Feb 18, 2012, at 8:27 PM, Thomas Herbst wrote:

> networks, but I understand having everyone use our constants for their> smaller networks may make the smaller networks slower than necessary.
>
> Someone putting an unconfigured device on a network should work.  Best> case would be the unconfigured device would work efficiently.
>
>
>
> Tom
> core at ietf.org<http://ietf.org>

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com<http://www.sensinode.com/>http://zachshelby.org<http://zachshelby.org/>  - My blog "On the Internet of Things"
http://6lowpan.net<http://6lowpan.net/> - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297<tel:%2B358%2040%207796297>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Feb 2012 18:53:50 +0100

> The values  for RESPONSE_TIMEOUT,  RESPONSE_RANDOM_FACTOR, and MAX_RETRANSMIT may be configured to network specific values, but the configuration method is out of scope of this document.  It is rec…

Thanks!
We probably want to replace "network" by something more general, as the network characteristics are not the only factor in choosing good values -- one also has to look at application requirements for timeliness and delivery probabilities etc.  E.g., some applications' networks will "the Internet", and there won't be a single set of values right for those applications...

maybe:
… to values specific on the application environment …
… that an application environment employ consistent …

In the long run, I expect many implementations will be able to employ adaptive schemes for configuring the values.  But, as you said, this is out of scope for this document.

Thanks again for bringing this up; it is important we get this right.

Grüße, Carsten