Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt

On Thursday 17 July 2008, Joe Touch wrote:
> Adam Langley wrote:
> > On Wed, Jul 16, 2008 at 3:38 PM, Joe Touch <touch@isi.edu> wrote:
> >> Both of these seem strange. They end up making the end of the option
> >> align, but disturb the front of the option. Why don't they pad at the
> >> end?
> >
> > So here's my hypothesis (and it's only a guess really):
> >
> > It's good to write in 32-bit words for speed reasons. Also, some
> > architectures make writing non-aligned 32-bit words hard. Now,
> > consider the SACK and timestamp options, you want to write a 32-bit
> > header followed by a payload (2 32-bit words for timestamp and 2*n
> > words for SACK). So you want the payload to be 32-bit aligned for both
> > writing and reading.
>
> That makes sense, but putting the pad at the beginning of every option
> vs. at the end of that option makes no sense AFIACT.

If I see this correctly, it makes no difference at all since the padding will 
be added after all. It seems more as a matter of programming convenience. 
Indeed TIMESTAMPs, SACK and MD5 are added with 16 bit padding each in data 
segments and something similar happens for syn segments too.

> (putting the pad for each option is inefficient, esp. since options
> aren't all that big a space and need to be byte-parsed anyway).

(In linux kernel) When using timestamps and SACK, a word (32bits) is filled 
with NOPs.I believe that the current approach is an accepted one since it 
doesn't violate any RFC and it doesn't reduce the available space long enough 
to cause problems. Is there a way that the extra 32 bits could be used (as of 
today)?

Apart from that, I believe that you (we) should fill a bug report.

FYI: Git shows that the oldest corresponding lines were last changed at 2006 
by Stephen Hemminger and Yoshifuji Hideaki.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm