------------------------------------------------------------ Additional possibilities of dealing with misbehaving servers ------------------------------------------------------------ This text discusses alternative possibilities of feature negotiation during connection that a client has when it finds that the Response sent by the server, after the client sent a Request with Change options, does not contain the expected Confirm options. 1. First alternative: drop Response and retransmit the Request -------------------------------------------------------------- If a Response is received, but without the expected Confirm option(s), then the client could perform feature-negotiation retransmission by dropping (ignoring) the Response, and retransmitting its Request (including the Change) option. The client would thus be prevented from entering PARTOPEN and the measure is even in agreement with the protocol event processing rules (8.1), as: "Every valid DCCP-Request received while the server is in the RESPOND state MUST elicit a new DCCP-Response" (8.1.3). For the implementation this choice has been rejected since if the server has a bug in not answering Change options, it is likely that the second Response will still have the expected Confirm options missing, which is also part of the reason the second alternative has not been considered. 2. Second alternative: use Ack-reply of Response to retransmit Changes ---------------------------------------------------------------------- The second alternative for feature-negotiation retransmission is to accept the Response, while retransmitting the still unconfirmed Change options on the Ack that it is sent prior to entering PARTOPEN state. For the following reasons this choice is not a good idea. Firstly, the server will as a subsequent consequence enter OPEN state, which implies by its definition that it now may send data. If however the feature negotiation at the client still remains unresolved, the server would then start transmitting data over a half-connection whose features are partially or even fully undefined. As a worst-case scenario, suppose that the client started to negotiate the use of both CCID3 and a sequence window of Wmin=32. The server in the above described state starts transmitting using the feature-defaults of a Sequence Window of 100 and a CCID of CCID2 (6.4); the latter mandating the use of Ack Vectors by implication (RFC 4341, 4.). Since the rules of feature negotiation state that old values must be used until the new ones have been confirmed (6.6.1), the client is bound to use the defaults as long as there is still no matching Confirm from the server. To repeat, a half-connection whose features are being negotiated should not be used for data traffic (8.2). Consider for instance the Sequence Window move from 100 to 32, where the client has sent the Change L for this NN-feature. This change affects both the sequence window at the server and the acknowledgment window at the client (7.5.2). If the client were allowed to send data before its pending feature negotiation has completed, then there is problem #1: if the client had packets in flight, then at which time shall the server switch its sequence window from 100 to 32? Switching too early will mean that valid client packets will be classified as sequence-invalid (7.5.3); switching too late could mean that the server eventually gets out of sync. The same problem needs to be addressed for the acknowledgment window at the client. [ Note that for the specific problem presented above a specific fix might be used as offered in 7.5.4, by keeping potentially sequence-invalid packets (which MUST not be processed other than by generating Sync packets) for up to two round-trip-times. In terms of implementability, this increases the demands on memory and on processing complexity. Firstly, storing up to two RTT's worth of received packets can, in the case of high-speed links with large RTTs (LFNs), drain the available memory allocated on a socket. Secondly, such storage requires further processing rules to answer the associated questions such as "why are these sequence-invalid packets stored", "when will they be discarded, timed-out, or promoted to sequence-valid packets", "to which event (passive/active negotiation) is the promotion tied", and the like. ] Thus, the consequence is not to allow data traffic as long as feature negotiation of the traffic parameters is in progress (8.2). But even so, if the client traffic is disabled due to the pending negotiation, the server still thinks that it may transmit data (since it has entered the OPEN state after receiving the Ack from the client), we have problem #2: the sequence window at the server also affects the acknowledgment traffic from the client (since Ack packets are subject to the same sequence-validity rules as Data packets). If the server produces high-rate traffic, then switching from W=100 to W=32 raises the same ambiguity problem for the sequence numbers of the acknowledgment traffic from the client (compare also the notes regarding the choice of SWL and AWL at the end of 7.5.1). The upshot, therefore, is that data transfer needs to be suspended until the relevant traffic parameters have been negotiated. Applied to the present scenario, it is thus as a consequence not a good idea to let the client retransmit its unconfirmed Change option via the Ack sent in reply to the received Response packet, since this causes the endpoints to the data-transfer states OPEN and PARTOPEN, respectively. Using the retransmissions of the Requests is, in contrast, the better alternative, since it prevents both negotiating sides from entering these data transfer states before the relevant transfer parameters have been fully negotiated.