Re: [core] draft-ietf-core-coap-06 Congestion Control

[Carsten Bormann <[e-mail]>]

> It's not clear to me that the drafts is a stop and wait congestion control. I can't see what stops parallel transaction to the same destination. Related to this, when doing non confirmable transaction, it does not seem clear how the congestion control works. Given the schema is stop and wait, I expect that this means one a request has been sent, a parallel request can not be initiated until a responses is received but I don't see text to that effect. 

I think this is related to being able to open multiple TCP connections at the same time.

RFC2616 had a "SHOULD" limit of up to two simultaneous TCP connections to the same server from one client.  This has become unpopular.

draft-ietf-httpbis-p1-messaging-14.txt says this (and has been saying it for a while):

   Clients (including proxies) SHOULD limit the number of simultaneous
   connections that they maintain to a given server (including proxies).

   Previous revisions of HTTP gave a specific number of connections as a
   ceiling, but this was found to be impractical for many applications.
   As a result, this specification does not mandate a particular maximum
   number of connections, but instead encourages clients to be
   conservative when opening multiple connections.

I would expect us to come up with similar text, but not limiting connections, but simultaneously outstanding interactions, where these are either CON/ACK interactions (message layer) or NON-based request/response interactions.
Section 3.2 of draft-eggert-core-congestion-control-01.txt suggests a possible direction for developing an algorithm that might be used, but as with TCP, I'd rather keep the algorithm separate from the protocol.

The remaining issue is how to congestion-control responses that are not 1:1 with requests, e.g. NON responses with mechanisms such as observe and responses to multicast requests.

> The draft also needs some sort of request timeout definition. Should address things like if A has an outstanding request to B, and A receives separate request from B, what happens. We don't want any glare problems.

I'm not sure I understand that part.  Yes, the cc state for NON-based request/response interactions has to time out (the one for CON/ACK does so automatically), say, at 4*MSL.  And, yes, if I send 20 NON requests, one each hour, the server might send all 20 responses at midnight at once.  This temporal decoupling is a variation of the non-1:1 aspect above and could be solved the same way.

Gruesse, Carsten