QUESTION : Feature length about the non-negotiable feature
Now non-negotiable feature does not has a fix size, it's length is decide by the value of the non-negotiable feature. For example, the client send Sequence Window Feature as the following: 0x23 0x04 0x03 0x64, the Sequence Window Feature has the length of 1-byte only.
But RFC4340 said:
7.5.2. Sequence Window Feature
Sequence Window has feature number 3 and is non-negotiable. It
takes 48-bit (6-byte) integer values, like DCCP sequence numbers. Change and Confirm options for Sequence Window are therefore 9 bytes long.
Is this correct? Or there are some RFCs said the non-negotiable feature has variable length?
Quoting Wei Yongjun:
Quoted 7 lines
Now non-negotiable feature does not has a fix size, it's length is decide by the value of the non-negotiable feature. For example, the client send Sequence Window Feature as the following:
0x230x040x030x64, the Sequence Window Feature has the length of 1-byte only.But RFC4340 said:
Quoted 8 lines
7.5.2. Sequence Window Feature
Sequence Window has feature number 3 and is non-negotiable. It takes
48-bit (6-byte) integer values, like DCCP sequence numbers. Change and Confirm options for Sequence Window are therefore 9 bytes long.Is this correct? Or there are some RFCs said the non-negotiable feature has variable length?
You are correct - the RFC states fixed lenghts, even if values can be communicated in much smaller options.
The implementation does not implement the fixed lengths suggested by the RFC, since this does not make sense. The implementation will always chose the smallest-possible container length.
I believe that this is the preferrable approach. In particular since DCCP is a protocol which has a special header flag (`X') to allow saving 3 bytes. Why use 6 bytes when the value fits comfortably in a single byte?
Moreover, a lot of problems are generated by all these copious option lengths - unless using very small payloads, it is easily possible to exceed the maximum packet size.
Thus, although the RFC says otherwise, I think that using the smallest option size for a given value is the right thing to do.
Implementing this option as variable length is not RFC compliant. If you would like to be forwarded the discussion about fixed vs. variable length -- the option was originally variable length -- please let me know. Until then it is best to follow the RFC, assuming that you are trying to implement DCCP rather than something else.
Eddie
Quoted 38 lines · Gerrit Renker
Quoting Wei Yongjun:
Quoted 7 lines
Now non-negotiable feature does not has a fix size, it's length is decide by the value of the non-negotiable feature. For example, the client send Sequence Window Feature as the following:
0x230x040x030x64, the Sequence Window Feature has the length of 1-byte only.But RFC4340 said:
Quoted 8 lines
7.5.2. Sequence Window Feature
Sequence Window has feature number 3 and is non-negotiable. It takes
48-bit (6-byte) integer values, like DCCP sequence numbers. Change and Confirm options for Sequence Window are therefore 9 bytes long.Is this correct? Or there are some RFCs said the non-negotiable feature has variable length?
You are correct - the RFC states fixed lenghts, even if values can be communicated in much smaller options.
The implementation does not implement the fixed lengths suggested by the RFC, since this does not make sense. The implementation will always chose the smallest-possible container length.
I believe that this is the preferrable approach. In particular since DCCP is a protocol which has a special header flag (`X') to allow saving 3 bytes. Why use 6 bytes when the value fits comfortably in a single byte?
Moreover, a lot of problems are generated by all these copious option lengths - unless using very small payloads, it is easily possible to exceed the maximum packet size.
Thus, although the RFC says otherwise, I think that using the smallest option size for a given value is the right thing to do.
--
To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 30 lines · Gerrit Renker
Quoting Wei Yongjun:
Quoted 7 lines
Now non-negotiable feature does not has a fix size, it's length is decide by the value of the non-negotiable feature. For example, the client send Sequence Window Feature as the following:
0x230x040x030x64, the Sequence Window Feature has the length of 1-byte only.But RFC4340 said:
Quoted 9 lines
7.5.2. Sequence Window Feature
Sequence Window has feature number 3 and is non-negotiable. It takes
48-bit (6-byte) integer values, like DCCP sequence numbers. Change and Confirm options for Sequence Window are therefore 9 bytes long.Is this correct? Or there are some RFCs said the non-negotiable feature has variable length?
You are correct - the RFC states fixed lenghts, even if values can be communicated in much smaller options.
The implementation does not implement the fixed lengths suggested by the RFC, since this does not make sense. The implementation will always chose the smallest-possible container length.
I believe that this is the preferrable approach. In particular since DCCP is a protocol which has a special header flag (`X') to allow saving 3 bytes. Why use 6 bytes when the value fits comfortably in a single byte?
Quoted 8 lines
Moreover, a lot of problems are generated by all these copious option lengths - unless using very small payloads, it is easily possible to exceed the maximum packet size.
Thus, although the RFC says otherwise, I think that using the smallest option size for a given value is the right thing to do.
Yes, you can save some space for store more data, but this break the compatibility. If the other system implement follow the RFC, since those feature will be treat as invalid value. Also if it is set as mandatory option, assoc will be reset. endpoint with different implement can not talk to each other. That is the problem.
Quoted 6 lines
Quoted 5 lines
Thus, although the RFC says otherwise, I think that using the smallest option size for a given value is the right thing to do.
Quoted 6 lines
Yes, you can save some space for store more data, but this break the compatibility. If the other system implement follow the RFC, since those feature will be treat as invalid value. Also if it is set as mandatory option, assoc will be reset. endpoint with different implement can not talk to each other. That is the problem.
After your email yesterday I checked the RFC and found it indeed uses fixed lengths. I have therefore updated the code so that the NN options have the described fixed lengths (Ack Ratio = 2, Sequence Window = 6).
This has been tested, I will post the changelog for the test tree shortly and upload the amended tree. I would be grateful if you could give this a spin with your test cases.
Thanks again.
Gerrit
Quoted 3 lines
Implementing this option as variable length is not RFC compliant. If you would like to be forwarded the discussion about fixed vs. variable length -- the option was originally variable length -- please let me know.
Yes, it would be good to forward this as input. I found three problems with using fixed-length (as opposed to variable-length) NN-options:
(1) Non-negotiable options are much more part of the traffic than some server-priority options such as e.g. the CCID or Allow Short Seqnos:
- Sequence Window should be set as the connection progresses (7.5.2);
- Ack Ratio is updated for each congestion window (RFC 4341, 6.1.2).
(2) Increased overhead
The feature default values of Ack Ratio (2) and Sequence Window (100) both fit into one byte. For small Sequence Windows, using a fixed-size option incurs an overhead of unused header space up to 5 bytes. For Ack Ratio this is less (1 byte), but the overheads accumulate on a global basis when the sizesare subtracted from the MPS.
(3) Consistency with other uses of header options
(a) NDP Count
The NDP Count option is variable-length (1..6 bytes), RFC 4340, 7.7 encourages to use the smallest container format.
(b) Timestamp Echo Option
When the Elapsed Time area of the Timestamp Echo Option is used, section 13.3 encourages to use the smallest variant of the option that can hold the relevant Elapsed Time value.
From what I can see, fixed lengths for NN options are mentioned in sections 6.5, 6.6.8, 7.5.2, and 11.3.
Quoted 12 lines · Gerrit Renker
Quoted 5 lines
Quoted 5 lines
Thus, although the RFC says otherwise, I think that using the smallest option size for a given value is the right thing to do.
Quoted 7 lines
Yes, you can save some space for store more data, but this break the compatibility. If the other system implement follow the RFC, since those feature will be treat as invalid value. Also if it is set as mandatory option, assoc will be reset. endpoint with different implement can not talk to each other. That is the problem.
Quoted 9 lines
After your email yesterday I checked the RFC and found it indeed uses fixed lengths. I have therefore updated the code so that the NN options have the described fixed lengths (Ack Ratio = 2, Sequence Window = 6).
This has been tested, I will post the changelog for the test tree shortly and upload the amended tree. I would be grateful if you could give this a spin with your test cases.
With the patch, it is OK for send non-negotiable features. But not valid for check invalid value when recv.
Quoted 10 lines
Quoted 5 lines
This has been tested, I will post the changelog for the test tree shortly and upload the amended tree. I would be grateful if you could give this a spin with your test cases.
With the patch, it is OK for send non-negotiable features. But not valid for check invalid value when recv.
Thank you for testing. I don't understand your second sentence: all NN options are value-checked, i.e. if you try a Sequence Window of less than 32 or greater than 2^46-1, the connection should be reset. Likewise, Ack Ratio is checked to be in the range 0..0xFFFF.
I guess you are meaning length' rather than value'.
It is certainly possible to implement that.
But it will kill any connection which has NN options with a valid value but unorthodox length. If that is what people want, then the following happens:
* NN Change L arrives with valid value, but results in an empty Confirm R since the length is unorthodox with regard to RFC 4340;
* receiving empty Confirm R resets the connection;
* with mandatory options the Reset will happen even earlier;
* a NN Confirm R with valid value (i.e. corresponding to the original value of the Change L) resets the connection as per RFC 4340, 6.6.8.
The RFC doesn't really require that you reset the connection just if the length is strange. Accepting valid values expressed in an strange length, but generating only the required lengths, seems like a good application of the TCP robustness principle ("be conservative in what you do, be liberal in what you accept from others", explicitly in RFC4340 3.6).
The discussion on whether Sequence Window should be variable-length begins here:
http://www.ietf.org/mail-archive/web/dccp/current/msg01257.html
search for "MW5: Section 7.5.2, second paragraph"
The two followups have a bit more.
Magnus Westerlund was one of the IETF's expert reviewers for DCCP; his opinion carried some weight. Probably I folded too early (I thought the extra "complexity" of a variable-length option wouldn't matter, and the option might occur frequently).
One solution might be a "dccp_pedantic" sysctl, defaulting to 0, where Linux DCCP is guaranteed to be RFC compliant only if "dccp_pedantic" is 1. (And Sequence Window is variable-length if "dccp_pedantic" is 0.)
Eddie
Quoted 31 lines · Gerrit Renker
Quoted 9 lines
Quoted 5 lines
This has been tested, I will post the changelog for the test tree shortly and upload the amended tree. I would be grateful if you could give this a spin with your test cases.
With the patch, it is OK for send non-negotiable features. But not valid for check invalid value when recv.
Thank you for testing. I don't understand your second sentence: all NN options are value-checked, i.e. if you try a Sequence Window of less than 32 or greater than 2^46-1, the connection should be reset. Likewise, Ack Ratio is checked to be in the range 0..0xFFFF.
I guess you are meaning
length' rather thanvalue'.It is certainly possible to implement that.
But it will kill any connection which has NN options with a valid value but unorthodox length. If that is what people want, then the following happens:
* NN Change L arrives with valid value, but results in an empty Confirm R since the length is unorthodox with regard to RFC 4340;
* receiving empty Confirm R resets the connection;
* with mandatory options the Reset will happen even earlier;
* a NN Confirm R with valid value (i.e. corresponding to the original value of the Change L) resets the connection as per RFC 4340, 6.6.8.
--
To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines
The RFC doesn't really require that you reset the connection just if the length is strange. Accepting valid values expressed in an strange length, but generating only the required lengths, seems like a good application of the TCP robustness principle ("be conservative in what you do, be liberal in what you accept from others", explicitly in RFC4340 3.6).
Thank you for the input. I had written this with possible forthcoming inter-op tests in mind. What Wei is doing is in principle also an inter-op test, with the difference that it uses and automated test stack.
Quoted 5 lines
The discussion on whether Sequence Window should be variable-length begins here:
http://www.ietf.org/mail-archive/web/dccp/current/msg01257.html
search for "MW5: Section 7.5.2, second paragraph"
Quoted 7 lines
The two followups have a bit more.
Magnus Westerlund was one of the IETF's expert reviewers for DCCP; his opinion carried some weight. Probably I folded too early (I thought the extra "complexity" of a variable-length option wouldn't matter, and the option might occur frequently).
There are several arguments which raise questions:
(1) Making it variable-length increases code complexity
I think this is not very relevant. The reason is that any option also needs to be converted into network-byte order (3.1). When the quantities are not 16 or 32 bit, the htons/htonl functions can not be used. Arnaldo has written a very clever function dccp_encode_value_var() which does both the byte-order conversion and the variable-length copy in one swoop. So there is little overhead in making it variable-lengh. And for the receiver code the case is similar.
(2) This option occurs infrequently
Agree with the above point: NN options are exchanged during the established phase and so it depends how frequently they appear. In any case they are retransmitted until acknowledged, which is one point that increases the frequency.
If there is a path change or the application increases/decreases the sending rate then Sequence Window also needs to be updated, hence "occurs infrequently" is not always true.
It is costly for the loss detection and the Ack Vector length to get out of synch, so it seems better to update the Sequence Window frequently (i.e. when it changes) rather than risking a "Step 6 failed" (8.5).
(3) Header compression
This did not occur in the discussion but someone mentioned a header compression argument as a possible cause for keeping the option fixed length. The gain for header compression seems low, since Change options are only sent if one endpoint leaves the STABLE state (6.6.2) and thus the value of subsequent Change options on the same path will always have different values.
Quoted 3 lines
One solution might be a "
dccp_pedantic" sysctl, defaulting to 0, where Linux DCCP is guaranteed to be RFC compliant only if "dccp_pedantic" is
1. (And Sequence Window is variable-length if "dccp_pedantic" is 0.)
I think this refers to the length of outgoing options? In any event, if people wanted to test different behaviours, it could be made a Kconfig menu option.
Gerrit