| * the spec and the code allow to have different CCIDs for forward and return path; | * this is foremost a theoretical thing - it is like having e.g. TCP Reno for the data and | TCP Hybla for the Acks that come back; | * but the practical implementation causes no end of headaches: | - With regard to Ian's suggestion, Ack Vectors must be enabled if at least one CCID is CCID2. | - If CCID2 talks to CCID3 then CCID2 will want to have its Ack Vectors from the CCID3 peer. | However, there is no CCID3 code to support Ack Vectors at the moment (and in the spec this | is only implicit). | - If CCID3 talks to CCID2 then CCID3 will want its X_recv and loss rate from the CCID2 peer. | But how? CCID2 doesn't know these things. The above is not correct, so please forget it. Furthermore, code which assumes that TX/RX CCID are always the same is ugly and will sooner or later break, so it is also not an option. With regard to the Ack Vectors, my suggestion however is * to remove the sysctl - it is confusing; * to make the use of Ack Vectors dependent on the current RX CCID; * the TX CCID need not be considered for the Ack Vector allocation, since the `Send Ack Vector' feature is server-priority (RFC 4340, 6.4) and thus negotiated by the side which has the RX CCID; * optional and for debugging: disabling of Ack Vectors in the Kconfig menu. - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
