Subject: [core] Congestion control in draft-ietf-core-coap-09?

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 29 Apr 2012 23:37:45 +0200

Hi,

Cullen asked tsv-dir for feedback on draft-ietf-core-coap-09. Please find below some thoughts after scanning through the TCP-like functions. This is not a formal tsv-dir review, but I have raised similar concerns for other drafts in past tsv-dir reviews. Unfortunately I have not followed the core WG. I apologize for my ignorance about the background (I am also not subscribed to the core list, so please CC me if needed).

>    be randomized.  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.

At first sight, the RTT is not mentioned elsewhere in the document. Is my understanding correct that core does not measure the RTT? If so, it is not clear to me how a sender would know the "expected maxium round trip time".

Also, note that if the intention is to ensure uniqueness of messages, the Maximum Segment Lifetime (MSL) matters. RFC 793 (arbitrarily) sets it to 2 minutes for TCP.

> 4.6.  Congestion Control
> 
>    Basic congestion control for CoAP is provided by the exponential
>    back-off mechanism in Section 4.1.

In my understanding, Section 4.1 defines a reliability mechanism with exponential back-off. Timer backoff is a pre-requisite for congestion control. But a backoff mechanism alone does not provide congestion control.

>    In order not to cause congestion, Clients (including 
> proxies) SHOULD
>    strictly limit the number of simultaneous outstanding interactions
>    that they maintain to a given server (including proxies).  An
>    outstanding interaction is either a CON for which an ACK 
> has not yet
>    been received but is still expected (message layer) or a 
> request for
>    which a response has not yet been received but is still expected
>    (which may both occur at the same time, counting as one outstanding
>    interaction).  A good value for this limit is the number 1.  (Note
>    that [RFC2616], in trying to achieve a similar objective, 
> did specify
>    a specific number of simultaneous connections as a ceiling.  While
>    revising [RFC2616], this was found to be impractical for many
>    applications [I-D.ietf-httpbis-p1-messaging].  For the same
>    considerations, this specification does not mandate a particular
>    maximum number of outstanding interactions, but instead encourages
>    clients to be conservative when initiating interactions.)

If there is no limitation of the number of outstanding interactions, I don't understand how congestion control is actually achieved. Also, note that RFC2616 is about a limit for TCP connections, which is not the same.

I think that this document should consider and discuss the guidelines of RFC 5405.

For instance, the following guideline therein matters: "It is important to stress that an application SHOULD perform congestion control over all UDP traffic it sends to a destination, independently from how it generates this traffic.  For example, an application that forks multiple worker processes or otherwise uses multiple sockets to generate UDP datagrams SHOULD perform congestion control over the aggregate traffic."

As long as there is only one outstanding interaction, the core protocol seems to fall into the class of "low data-volume applications" according to section 3.1.2 of RFC 5405. In that case, an exponential backoff of the retransmission timer is considered sufficient for congestion control. Thus, for that case, the protocol mechanisms defined in the draft seem to be sufficient.

However, the text only mentions that "A good value for this limit is the number 1". This is too weak, imho. I think that this should be at least a SHOULD, and the section should refer to RFC 5405. Also, I think that the document should explain that using any value significantly larger than one will require implementation of an aggregate, TCP-friendly congestion control, e. g., by adapting the limit according to the observed packet loss (this won't be trivial).

>    Further congestion control optimizations and considerations are
>    expected in the future, which may for example provide automatic
>    initialization of the CoAP constants defined in Section 9.

As already mentioned, congestion control might also have to control the limit of interactions, if the value is larger than 1.

> 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

These values seem to be OK.

>    The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and
>    MAX_RETRANSMIT may be configured to values specific to the
>    application environment, however the configuration method is out of
>    scope of this document.  It is recommended that an application
>    environment use consistent values for these parameters.

A decrease of RESPONSE_TIMEOUT below 1 second would violate the guidelines of RFC 5405, and it would not be save for use in the Internet.

Also note that significantly decreasing the RESPONSE_TIMEOUT would require an adaptive RTT measurement to be robust, see RFC 5405 or draft-allman-tcpm-rto-consider. I think that the draft should strongly discourage any decrease of RESPONSE_TIMOUT until such more advanced mechanisms exist, and it should explain why.

Thanks

Michael