Subject: [core] Fwd: I-D Action:draft-eggert-core-congestion-control-00.txt

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jun 2010 11:22:37 +0300

FYI. I'd be interested in discussing the ideas in this draft with the WG.

> A New Internet-Draft is available from the on-line Internet-Drafts directories. 
>  
> Title : Congestion Control for the Constrained Application Protocol (CoAP) 
> Author(s) : L. Eggert 
> Filename : draft-eggert-core-congestion-control-00.txt 
> Pages : 9 
> Date : 2010-06-23 
>  
> The Constrained Application Protocol (CoAP) is a simple, low- 
> overhead, UDP-based protocol for use with resource-constrained IP 
> networks and nodes. CoAP defines a simple technique to individually 
> retransmit lost messages, but has no other congestion control 
> mechanisms. This document motivates the need for additional 
> congestion control mechanisms, and defines some simple strawman 
> proposals. The goal is to encourage experimentation with these and 
> other proposals, in order to determine which mechanisms are feasible 
> to implement on resource-constrained nodes and are effective real 
> deployments. 
>  
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-eggert-core-congestion-control-00.txt

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 24 Jun 2010 12:00:09 +0200

I like a lot your contribution on congestion control (totally missing).

Transmission credits and RTT estimation are two important improvements
to CoAP in my opinion...

Just a note, you define in your document that there is an aggregate
limit on the outstanding number of transactions that a node can
produce.. I was wondering if this congestion control technique is
leaving two problems open:

a) A CoAP server provides 1/many "popular" resources. Many clients may
send concurrent requests to the server, and the server concurrent
responses.

The responses should be concurring to the "tx credit"? (in my opinion yes)

The server cannot directly know whether the sent response has been
received, how can responses partecipate to the Reno-like AIMD scheme
depicted in the document? (in my opinion a response can be considered
to be "correctly received" if the server doesn't receive in the
subsequent time window of X seconds a retransmission of the served
request)

b) "big-I" Internet <-> Constrained nodes island intercommunication is
*probably* a congestion bottleneck that is harder to handle. Is this
scheme sufficient to handle congestion on a highly congested path that
may be formed by very constrained relays?

I suspect that handling these problems may lead to very specific
discussion on transport that is probably out-of-scope in this WG.

Regards,
Angelo

On Thu, Jun 24, 2010 at 10:22, Lars Eggert <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jun 2010 12:38:58 +0200

> http://www.ietf.org/internet-drafts/draft-eggert-core-congestion-control-00.txt 

Hi Lars,

this is very useful early input (and might help us prevent late surprises at the IESG stage).  Thanks!

One thing we need to be vary careful about is the burden we place on implementers/implementations.
After all, these are constrained nodes, and both code and table (data) sizes are constrained.

What could happen is that we mandate something wonderful that then nobody implements.

Keeping RTT information about other nodes creates a table that other protocols such as ND or RPL take great pains to avoid.
There should always be a mode of operation (not necessarily optimal) that avoids creating tables such as this.
More power [sic!] to nodes that can implement them, they will have better performance.

I do like the credit proposal.
If we could phrase this in a way that helps a very constrained node to keep tabs on its battery usage as well, this might be a winner.

Most importantly though, we need a lot of time to answer these questions well (there is a reason transport development takes time).
If we can find minimal requirements that can be put into the document and leave open the way to plug in better algorithms, we can have fruitful evolution.

With some danger of creating a controversial strawman for this: We could say "at a minimum use a fixed initial RTO of 3 s and exponential backoff and don't run more than a couple parallel requests, or keep RTT and credit information and do something better".

Gruesse, Carsten

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jun 2010 13:49:44 +0300

Hi,

> What could happen is that we mandate something wonderful that then nobody implements.

fully understood. Implementation feasibility is definitely something that we need to learn about, based on experimenting with these and other techniques.

> More power [sic!] to nodes that can implement them, they will have better performance.

Also agreed. I believe in the end, we'll have a toolbox of techniques, from coarse but simple (for very constrained devices) to techniques that are a bit more complex.

> If we can find minimal requirements that can be put into the document and leave open the way to plug in better algorithms, we can have fruitful evolution.

Agreed. I earlier commented to Zach (off list) that the base protocol specification can move forward without needing to wait for the development of these congestion control techniques. We may at this time simply want to include a pointer to the document as an attention grabber so that implementors know that some additional functions may come down the pipe in the future.

> With some danger of creating a controversial strawman for this: We could say "at a minimum use a fixed initial RTO of 3 s and exponential backoff and don't run more than a couple parallel requests,…

Sounds much what I had in mind.

Oh, and we do need to actually experiment with these techniques :-)

Lars

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 Jun 2010 22:26:19 +0300

> With some danger of creating a controversial strawman for this: We could say "at a minimum use a fixed initial RTO of 3 s and exponential backoff and don't run more than a couple parallel requests,…

I like that, but let's wait and add something like that after coap-01 when we have some more implementation experience.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297