Quoting Ian McDonald:
| > [DCCP]: Always support Ack Vectors
| >
| > This removes CONFIG_IP_DCCP_ACKVEC for reasons of inter-operability.
| >
| > In RFC 4340 requires CCID2 as a kind of default (section 10):
| > "A DCCP implementation intended for general use, such as an implementation
| > in a general-purpose operating system kernel, SHOULD implement at least CCID 2.2
| >
| > RFC 4341, section 4 says that the use of "Ack Vector is MANDATORY on CCID 2 half-connections".
| > (This was so far ensured via Kconfig option). New connections start with CCID 2 for both
| > endpoints [RFC 4340, sec. 10]
| >
| > Taken together this indicates that Ack Vectors should not be disabled in the build process.
| >
| > Signed-off-by: Gerrit Renker <gerrit@xxxxxxxxxxxxxx>
|
| NAK.
|
| Only CCID2 needs Ack vectors, CCID3 doesn't.
|
This is not so much about which CCID needs but about a minimally-compliant implementation in
terms of compile-time options. The point that I wanted to make is the following:
DCCP mandates a `minimum implementation' = CCID2
==> CCID2 mandates Ack Vectors
==> Ack Vectors are not optional but mandatory
| If we're going to tidy this up the code should be conditional on
| CCID2. As I read this you're making it conditional on DCCP.
Hm maybe that is your point - I have just checked, one can actually still disable CCID2 in Kconfig
- did you mean that? In any case, using DCCP entirely without CCIDs is pointless, it will simply
not work. And this is a bug - a user who disables both CCIDs ends up with a DCCP stack which will
simply not work (there is no `null' CCID).
Using CCID3 only, on the other hand, does not agree with the RFC4340 idea of an implementation which
minimally speaks CCID2.
I think your point is valid, from my perspective the best thing seems to remove CCID2 from the optional
state in Kconfig and make it a fixed default.
The other point you are raising is about _setting_ (as opposed to compiling) the CCIDs, and here I
agree, more work can be done.
| While we're at, we should turn ack vectors off by default for CCID3
| (if they're built) and on for CCID2.
That is a good point and definitively something to add when we have discussed what and how this
patch should be realised.
| If you want me to come up with an alternative patch, please tell me.
Please do - it can only be good to discuss the different ideas, and maybe we can come up with an
even better solution.
-
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
