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

[Wei Yongjun <yjwei@cn.fujitsu.com>]

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.