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

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 <lars.eggert@nokia.com> wrote:
> 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
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>