From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eddie Kohler Date: Tue, 17 Jun 2008 14:08:08 +0000 Subject: Re: QUESTION : Feature length about the non-negotiable feature Message-Id: <4857C548.8000008@cs.ucla.edu> List-Id: References: <48579530.4010807@cn.fujitsu.com> In-Reply-To: <48579530.4010807@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: dccp@vger.kernel.org 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