Background on Feature Negotiation

This page summarises the background information on feature negotiation, extracted from RFC 4340.

1. General

1.1 The location of features

When negotiating features, it is important to be clear about the location of the feature. DCCP uses the notion of half-connections, which means that for each feature there are two possible locations - either the at the TX side, or at the RX side of a half-connection. A further consequence of this is that on each host every feature exists twice: once as feature-local (at the RX or TX side of a half-connection), and once as feature-remote (at the TX or RX side, respectively).

With regard to the congestion control (CCID) feature, in the above picture we thus have that the

local TX CCID of A is the remote RX CCID of B,
local RX CCID of A is the remote TX CCID of A.

The following table lists the currently defined features and their locations as defined throughout RFC 4340.

Number	Meaning	Feature Location		Type	Init.	Reconc.		Section
Number	Meaning	RX	TX	Type	Init.	SP	NN	Section
1	CCID		X	List(2,3)	{2}	X		10
2	Allow Short Seqnos		X	Bool	{0}	X		7.6.1
3	Sequence Window		X	48-bit Int.	100		X	7.5.2
4	ECN Incapable	X		Bool	{0}	X		12.1
5	Ack Ratio		X	16-bit Int.	2		X	11.3
6	Send Ack Vector	X		Bool	{0}	X		11.5
7	Send NDP Count		X	Bool	{0}	X		7.7.2
8	Min. Checksum Coverage	X		List(0..15)	{0}	X		9.2.1
9	Check Data Checksum	X		Bool	{0}	X		9.3.1
192	Send Loss Event Rate (ref. RFC 4342)	X		Bool	{0}	X		8.4

The last row contains the single currently defined CCID-specific feature, used by CCID3 (RFC 4342). CCID2 (RFC 4341) requires the ECN Capable, Ack Ratio, and Send Ack Vector features but does not define any new features.

Short notes on the location of features follow below.

1.1.1 Congestion Control ID (CCID)

The CCID operates on the traffic from sender (TX) to receiver, hence it is natural that the CCID feature location is at the TX side of the half-connection: "CCID/A value equals the CCID in use for the A-to-B half-connection" (RFC 4340, 10.). The following table shows CCID negotiation from the different perspectives (see also section 4.5 of RFC 4340).

Event	Client -> Server	Server -> Client
client changes its RX CCID	ChangeR(CCID, ...)
client changes its RX CCID		ConfirmL(CCID, ...)
client changes its TX CCID	ChangeL(CCID, ...)
client changes its TX CCID		ConfirmR(CCID, ...)
server changes its RX CCID		ChangeR(CCID, ...)
server changes its RX CCID	ConfirmL(CCID, ...)
server changes its TX CCID		ChangeL(CCID, ...)
server changes its TX CCID	ConfirmR(CCID, ...)

1.1.2 Allow Short Seqnos

Sequence numbers are a feature of the outgoing (data) traffic, hence the feature location of allowing short sequence numbers is at the TX side. From section 7.6.1 of RFC 4340: "DCCP A sends a `Change L(Allow Short Seqnos, 1)' option to indicate its desire to send packets with short sequence numbers."

1.1.3 Sequence Window

The Sequence Window feature determines how many packets a sender can have `in flight'; it is thus located at the TX side of a half-connection:

"DCCP A sends a `Change L(Sequence Window, W)' option to notify DCCP B that the Sequence Window/A value is W", under the constraint that
"DCCP A MUST NOT persistently send more than Sequence Window/A packets per RTT" (RFC 4340, 7.5.2).

A slightly confusing point in this regard is that the Sequence Window feature located at DCCP A also determines "the width of the Acknowledgement Number validity window used by DCCP A" (ibid). But this is clearer to understand when considering the acknowledgments provide the the feedback along the sender-receiver half-connection (compare with above figure).

1.1.4 ECN Incapable

ECN indicators of congestion (RFC 3168) are parsed by the receiver of ECN-marked messages. Hence this feature is a property located at the RX side of a connection: "If the ECN Incapable/A feature is one, then all of DCCP B's packets MUST be sent as ECN incapable" (RFC 4340, 12.1) . Hence this means for the receiver that if it "is not ECN capable, it MUST send Mandatory `Change L(ECN Incapable, 1)' options to the other endpoint until acknowledged (by `Confirm R(ECN Incapable, 1)') or the connection closes" (ibid).

1.1.5 Ack Ratio

"The Ack Ratio feature lets HC-Senders influence the rate at which HC-Receivers generate DCCP-Ack packets" (RFC 4340, 11.3). Hence this feature is located at the TX side of a half-connection - "the sender raises Ack Ratio when the reverse path is congested and lowers Ack Ratio when it is not" (ibid).

1.1.6 Send Ack Vector

Ack vector options (RFC 4340, 11.4) contain a run-length encoding of how (many) packets were received, hence the Send Ack Vector feature is located at the RX side of a half-connection: "DCCP B sends a `Change R(Send Ack Vector, 1)' option to DCCP A to ask A to send Ack Vector options as part of its acknowledgement traffic" (RFC 4340, 11.5).

Ack Vectors are mandatory in CCID2 (RFC 4341), for other CCIDs (such as CCID3) they are optional.

1.1.7 Send NDP Count

The sender uses this option to inform the receiving end about how many data/non-data packets it sends. "This lets the receiving DCCP reliably determine when a burst of loss included application data" (RFC 4340, sec. 7.7). Hence the feature is located at the TX side of a half-connection: "DCCP A sends a `Change R(Send NDP Count, 1)' option to ask DCCP B to send NDP Count options" (RFC 4340, sec. 7.7.2).

1.1.8 Minimum Checksum Coverage

DCCP, like UDP-Lite (RFC 3828), supports partial checksum coverage (RFC 4340, sec. 9.2). Receivers can set a minimum checksum coverage as a threshold, thereby indicating the minimum amount of checksum (coverage) protection that the receiver expects on its incoming packets. Hence the location of the Minimum Checksum Coverage feature is the RX side of a half-connection: "For example, DCCP A sends a `Change R(Minimum Checksum Coverage, 1)' option to DCCP B to check whether B is willing to accept packets with Checksum Coverage set to 1" (RFC 4340, sec. 9.2.1).

1.1.9 Check Data Checksum

The Data Checksum Option (RFC 4340, 9.3) contains a CRC-32 cyclic redundancy check generated by the sender. For successful use of this CRC, the Check Data Checksum feature indicates whether the receiver supports this; the feature is thus located at the RX side. If a sender requires that the receiver always checks the CRC, it must send a Mandatory `Change R(Check Data Checksum, 1)' option to the receiving side of the half-connection (RFC 4340, sec. 9.3.1).

1.1.10 Send Loss Event Rate

The feature number of 192 marks the Send Loss Event Rate feature as CCID-specific (RFC 4340, sec. 6.4), the precise assignment is found later in section 10.3: "option numbers 192 through 255 are for options sent from the HC-Receiver to the HC-Sender"; hence this feature is located at the RX side of a half-connection.
From section 8.4 of RFC 4342: "The Send Loss Event Rate feature lets CCID 3 endpoints negotiate whether the receiver MUST provide Loss Event Rate options on its acknowledgements. DCCP A sends a `Change R(Send Loss Event Rate, 1)' option to ask DCCP B to send Loss Event Rate options as part of its acknowledgement traffic."

1.2 Reversing the perspective

Depending on whether they are received or sent, the ChangeL/R and ConfirmR/L options can have the effect of reversing the perspective from which the feature location is referred to (see also 10.3).

Option Type	Operational Mode		Feature Location
Option Type	Receive	Send	RX	TX
Change L / Confirm L	X		TX	RX
Change L / Confirm L		X	/	/
Change R / Confirm R	X		/	/
Change R / Confirm R		X	TX	RX

A received Change L / Confirm L option refers to the feature location at the remote end, so at the local end it is the corresponding opposite location - a feature located at the remote RX side corresponds to the same feature at the local TX side. The situation is analogous when sending Change R / Confirm R - the local feature location translates into the opposite location at the remote end.

1.3 The type of features

Non-negotiable (NN) features all have a scalar (Integer) type, server-priority features have a list (powerset) type. In the table this is denoted by List(X), where X is the enumerated set; i.e. `List(x,y)' means that the list can have the form {}, {x}, {y}, or {x,y}. Note that empty lists are not valid for feature negotiation (RFC 4340, 6.1).

2. Feature negotiation

This section discusses the two currently known algorithms and details of their implementation.

2.1 Server-priority features (SP)

The following state diagram shows the negotiation of server-priority features at the feature remote (compare with the description of negotiation at the feature location in section 6.6.2 of RFC 4340).

Negotiation at the feature remote

2.1.1 Basic algorithm

The negotiation rule in section 6.3.1 of RFC 4340 says that "To reconcile the preference lists, select the first entry in the server's list that also occurs in the client's list. If there is no shared entry, the feature's value MUST NOT change, and the Confirm option will confirm the feature's previous value (unless the Change option was Mandatory; see Section 6.6.9)."

The termination of this algorithm depends on the Confirm option: when there is no shared entry, the peer confirms back its old value and preference list. Since this is incompatible with the local preference list (no shared entry), the reset condition for Confirm options from sections 6.6.8/9 of RFC 4340 is fulfilled: the connection is reset with Reset Code 5, "Option Error" (sec. 6.6.8). As an example, consider negotiation using singleton preference lists:

the client sends a ChangeR(CCID, {3});
server only supports CCID2 (default from 6.4) and responds with a ConfirmL(CCID, {2});
the selected value is invalid for the client (CCID2 not supported), hence the connection is reset.

The rule responsible for the termination of the algorithm can be found in 6.6.9, which states that the absence of a shared entry in the two (client/server) preference lists constitutes a reset condition for Mandatory Change options; and that "Confirm options behave identically and have the same reset conditions whether or not they are Mandatory".

The other possible outcome of this algorithm is that the peer does not understand the feature and/or its value and sends back an empty Confirm, in which case the old value and preference list must be used (6.6.7). The possible cases are summarised in the following diagram, where DCCP A initiates a feature negotiation for feature F, sending its preference list F_A.

Possible outcomes of SP feature negotiation

This list either agrees with DCCP B's preference list, resulting in a confirmed list of F_A'; or there is no shared entry so that DCCP B just sends its current preference list (F_B); or, lastly, DCCP B might send an empty Confirm.

2.1.2 Negotiating Boolean features

The reconciliation of a Boolean feature is the reconciliation of two Boolean lists. The following table lists the possible combinations, and the result, that occur when negotiating Boolean values.

Client

{0}

{1}

{0,1}

{1,0}

Server

{0}

{1}

{1,0}

{0,1}

{0}

{1}

{1,0}

{0,1}

{0}

{1}

{1,0}

{0,1}

{0}

{1}

{1,0}

{0,1}

Result

Fail

Here `Fail' means that the confirmation will echo the local choice to the requesting peer, and so we have the same situation as above - incompatible singleton lists, leading to resetting the connection. It is evident that a client preference list of either {0,1} or {1,0} signals a "don't care" - the result then only depends on the server's preference.

2.1.3 A note on preference lists

A particular case (which may reflect changing user priorities) is to change the preference list without changing the preferred value (the first entry). In these cases, the endpoint can remain in the STABLE state. However, if this happens in the CHANGING state, UNSTABLE must be entered until the corresponding Change option has been sent (6.6.5).

2.2 Non-negotiable features (NN)

Non-negotiable features are easier to validate: all currently known NN features (Sequence Window and Ack Ratio) are Integer values with range and length limitations; and furthermore, only ChangeL() may be received for NN features.
This also implies a much simpler state diagram than for server-priority features: at the feature location, this is similar to section 6.6.2 of RFC 4340, with the difference that ChangeR() options do no longer appear in the state diagram as they are invalid for NN options (6.3.2).
At the feature-remote, this is even simpler (6.3.2 and 6.6.9): since only the feature location can actively change the value, the state diagram reduces to a single state; the connection is reset if the ConfirmR() is not acceptable at the feature location.

Negotiation of NN features at the feature-remote

3. Algorithms

The next two subsections summarise the information about the processing of feature-negotiation options from RFC 4340.

3.1 Processing incoming Change options

The following flowcharts shows how incoming ChangeL/R options are processed.

3.2 Processing Confirm options

Analogously, processing incoming ConfirmR/L options is summarised in the following flowchart.