QUESTION : Feature length about the non-negotiable feature

QUESTION : Feature length about the non-negotiable feature

[Wei Yongjun]

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?

Re: QUESTION : Feature length about the non-negotiable feature

[Gerrit Renker]

Quoting Wei Yongjun:
> 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?
>
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.

Re: QUESTION : Feature length about the non-negotiable feature

[Eddie Kohler]

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


Gerrit Renker wrote:
> Quoting Wei Yongjun:
>> 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?
>>
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: QUESTION : Feature length about the non-negotiable feature

[Wei Yongjun]

Gerrit Renker wrote:
> Quoting Wei Yongjun:
>   
>> 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?
>>
>>     
> 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.
>
>   

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.

Re: QUESTION : Feature length about the non-negotiable feature

[Gerrit Renker]

>>
>> 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.
>
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

Re: QUESTION : Feature length about the non-negotiable feature

[Gerrit Renker]

> 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.

Re: QUESTION : Feature length about the non-negotiable feature

[Wei Yongjun]

Gerrit Renker wrote:
>>> 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.
>>
>>     
> 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.

Re: QUESTION : Feature length about the non-negotiable feature

[Gerrit Renker]

>> 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.

Re: QUESTION : Feature length about the non-negotiable feature

[Eddie Kohler]

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


Gerrit Renker wrote:
>>> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: QUESTION : Feature length about the non-negotiable feature

[Gerrit Renker]

> 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.

> 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).
>
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.


> 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