Why feature negotiation and protocol state machine are not independent



The specification (RFC 4340) treats feature negotiation and protocol state machine as independent, decoupled units. From a specification point of view, this seems pragmatic and appropriate: the specification is predominantly declarative, i.e. concerned with the what, much rather than the how, of feature negotiation. Secondly, intermingling the goals (of how feature negotiation is supposed to work) with instructions for their realisation would probably increase the complexity of the specification, and likely limit its scope to implementation-dependent assumptions.

From the implementation point of view, however, feature negotiation and protocol state machinery are not separate from each other; and it is dangerous to assume such an independence, since it can lead to undefined operational states as well as deadlock conditions.

The situation is like that of concurrent programming, where the programmer is free to define processes independently, but remains responsible for their correct interaction and for avoiding concurrency problems. This will be illustrated in the following sections.

1. The protocol state machine depends on feature negotiation status

DCCP A can not start data transmission to DCCP B as long as any features affecting the TX side of the A-to-B half-connection (located at DCCP A), and any features affecting the RX side of the A-to-B half-connection (located at DCCP B) are not in the STABLE state. (See here for an illustration of the half-connections.)

Consider what would for instance happen when the Sequence Window feature has not yet been negotiated - then the receiver, DCCP B, would have no idea of how to validate the sequence numbers of packets originating from A (7.5.1). As another example, suppose that DCCP A's TX side uses CCID3, while DCCP B's RX side uses CCID2; and DCCP A starts sending data traffic over the congestion-controlled A-to-B half-connection before the CCID feature has been fully negotiated (or the connection has been re-set due to incompatibility): a case of non-interoperable endpoints. Therefore, DCCP A must not send to DCCP B before the negotiation of features affecting transmission from A-to-B has stabilised, i.e. all involved features have reached the STABLE state of negotiation (in this regard, see also the note at the end of section 8.2 in RFC 4340).

The same issue arises for all the features affecting the feedback/acknowledgment traffic over the A-to-B half-connection, such as Ack Ratio (11.3) or Send Ack Vector (11.5). The latter, in turn, depends on the (earlier) choice/negotiation of the CCID feature: since CCID2 mandates the use of Ack Vectors (RFC 4341, sec. 4), negotiating a CCID of CCID2 implicitly entails the use of Ack Vectors.  Hence, before traffic on the A-to-B half-connection may begin (or resume), all TX features of DCCP A and all RX features of DCCP B must have been resolved into the STABLE state.

Since furthermore DCCP is a full-duplex protocol, by symmetry  the same considerations apply to the B-to-A half-connection: no traffic may use the B-to-A half-connection until the TX features of DCCP B and the RX features of DCCP A have been negotiated into STABLE state (or the connection has been reset due to unresolvable incompatibilities).

While in the individual case it might be possible to get around these complications by closing only the affected half-connection for traffic, in the general case the conclusion is that no data/acknowledgment traffic should flow whilst any host-local feature is still in the non-STABLE state.

For the protocol state machine this means to defer the transition from connection inititiation to the data transfer states. When feature negotiation is performed for an already established connection, traffic flow likewise needs to be suspended until the feature negotiation has reached convergence (8.2).

2. Feature negotiation is dependent on the individual protocol state

The actions taken by feature negotiation do not only depend on the feature-negotiation state machine (6.6.2), but also on the current state of the protocol machinery (8.4).

Firstly, feature negotiation has a different format depending on whether the connection is being set up or already fully established. A detailed study of feature negotiation during connection-setup can be found in a later section. Suffice it for the moment to consider that e.g. in the LISTEN state the endpoint has to wait for an incoming Request before it can send its Change option. If, on the other hand, the connection is already established, feature negotiation can transmit Change negotiation options immediately, using either Ack or Sync packets to perform the (re-)transmissions necessary to achieve reliability (6.1).

As a further difference, any other traffic must be suspended while the feature negotiation is in progress for an already established connection (cf. above); whereas this measure is not necessary when the connection is being set up.

Lastly, since DCCP does not have the notion of half-closed states, feature negotiation in the CLOSEREQ or CLOSING state is pointless and without effect; it should therefore not be performed.

The conclusion is thus that the actions taken by feature negotiation are contingent upon the particular current protocol state, and that some of the protocol states imply additional rules (such as suspending user traffic or effecting retransmissions).