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

From: Salvatore Loreto <[email-masked]>
Date: Fri, 16 Jul 2010 14:16:46 +0300

in line

/Sal

On 6/24/10 1:00 PM, Angelo P. Castellani wrote:
> 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)
>    
[Sal]
Section 3.1.2 of [RFC5405] recommends that such application protocols:
-employ congestion control for both directions of a bi-directional 
communication

so I also think that the right answer is 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?
>    
[Sal] that in some way means an interaction between the TCP congestion 
control and the
CoAP one...
> 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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Jul 2010 11:04:43 +0300

Hi,

> so I also think that the right answer is yes.

yes, the intent is that the send credits cover any transmission into the network, whether initiated by a local app or in response to a query from an app on another node, or even locally generated error messages.

>> subsequent time window of X seconds a retransmission of the served

Right. How you know that something got successfully delivered (so you can increase your send credit count for the next time interval) isn't well-defined at the moment, especially for unreliably transmitted messages. Another reason this is experimental...

> control and the CoAP one...

The intent is that the proposed send credit scheme is implemented by all COAP speakers, including those in the big-I Internet. If there is a translating gateway (e.g. HTTP<->COAP), then it needs to implement the scheme when sending into the COAP network.

Lars

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 20 Jul 2010 10:28:35 +0200

Hi,

thanks for the reply.

> The intent is that the proposed send credit scheme is implemented by all COAP speakers, including those in the big-I Internet. If there is a translating gateway (e.g. HTTP<->COAP), then it needs to…

Maybe a problem arise when multiple CoAP speakers are on the big-I
Internet, talking simultaneously with multiple CoAP speakers on the
LR-WPAN.

All this traffic has to go through the
IPv6/Ethernet<->6LoWPAN/802.15.4 gateway, that will easily became a
congestion bottleneck, both in the big-I -> LR-WPAN direction (easier
to handle through buffering), LR-WPAN -> big-I (harder to handle
because the 802.15.4 link between the GW and the nodes can have an
high number of hosts competing for the channel).

Best,
Angelo

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Jul 2010 11:36:43 +0300

Hi,

> high number of hosts competing for the channel).

right. So what will happen is that messages will be lost. This in turn will cause the COAP senders that emitted them to reduce their send credit budget during their next time interval, which will reduce the congestion on those links.

(With some hand-waving, because the send credits are obviously not accounted for per destination. This means that the budget will be reduced even if these nodes in the next time interval don't send messages across the proxy. But I at least can't come up with a simple scheme that would more accurately track this, or at least not one that would need some network feedback a'la ECN.)

Lars

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Jul 2010 16:07:02 +0200

[Another resend, sorry.]

> subsequent time window of X seconds a retransmission of the served

Two observations here.

First, any TCP server has the same problem with the SYN ACK.
Unless I have missed some recent work, we don't really know how to congestion control initial responses.

Yes, a CoAP response might be up to 20 times larger than a SYN ACK.
This is maybe one area where a CC algorithm could change something: 
The server could start sending smaller packets (using the block option).

Second, any retransmission of the original request by the other party will be subject to binary backoff.
It is not clear to me how a server could add to that, except by sending smaller packets (see above).

Since retransmissions should be done by the peer by using the same TID, a server can get a pretty good measurement of how many ACKs it needs to send to get one through.  This could go into per-peer or global CC state, in turn influencing the default block size.

Global state makes a lot of sense if the bottleneck is likely to be close to the server.

One other interesting observation:
The way the block option is defined right now, we assume a constant block size for all transactions in a transfer.
This helps simplifying things a lot, but reduces the granularity of adaptation possible in a packet-size adaptive CC algorithm.
I'd still rather stick with a constant block size.

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 20 Jul 2010 16:08:39 +0200

Hi,

> (With some hand-waving, because the send credits are obviously not accounted for per destination. This means that the budget will be reduced even if these nodes in the next time interval don't send…

I agree that ECN is the only solution I can think to this kind of
problem.. Maybe ECN are really useful in this environment.

CoAP big-I<->LR-WPAN gateways can be required to support ECN marking?

Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 20 Jul 2010 16:14:52 +0200

Hi,

> The server could start sending smaller packets (using the block option).

Sending smaller packets first and using block option could be an
useful addition I think.

Another issue about the tx credits definition: "Sending one CoAP
message consumes one transmission credit". But when we send a very big
CoAP message which results in 10 or more 802.15.4 PHY packets being
sent on the LR-WPAN, this can lead to some issues.

Probably TX credits should be more strictly related to the PHY MTU on
the path, which however requires a knowledge that the end-point could
not have. Moreover 6LoWPAN compression depends upon the IPv6 addresses
on the packet.. So can be hard to predict how many frames are required
to send a single CoAP message.

Angelo

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Jul 2010 17:19:00 +0300

> CoAP big-I<->LR-WPAN gateways can be required to support ECN marking?

It's not only the gateways that need to do ECN, it's all nodes that can potentially become bottlenecks - in other words, all of them. And ECN alone doesn't help, we also need to build mechanisms into COAP that do something useful with the information.

Lars

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Jul 2010 10:52:39 +0200

Two observations here.

Gruesse, Carsten