Message-ID: <487E809C.7090608@isi.edu>
Date: Wed, 16 Jul 2008 16:13:32 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Adam Langley <agl@imperialviolet.org>
References: <20080714234502.AC4793A69F4@core3.amsl.com>	
 <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com>	
 <396556a20807161040s21a6a081i326af08add5d7f4e@mail.gmail.com>	
 <487E6475.30107@isi.edu>	
 <396556a20807161454g14346470g89ce7d87ff4379c9@mail.gmail.com>	
 <487E7859.3090409@isi.edu>
 <396556a20807161609x455948f8qa40414799b64de72@mail.gmail.com>
In-Reply-To: <396556a20807161609x455948f8qa40414799b64de72@mail.gmail.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt
Precedence: list
Content-Type: multipart/mixed; boundary="===============0941871425=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0941871425==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigD05D4EDE71A53430B282FDF5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD05D4EDE71A53430B282FDF5
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable



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 a=
lign,
>> but disturb the front of the option. Why don't they pad at the end?
>=20
> So here's my hypothesis (and it's only a guess really):
>=20
> 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.=20

That makes sense, but putting the pad at the beginning of every option=20
vs. at the end of that option makes no sense AFIACT.

(putting the pad for each option is inefficient, esp. since options=20
aren't all that big a space and need to be byte-parsed anyway).

Joe


--------------enigD05D4EDE71A53430B282FDF5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIfoCjE5f5cImnZrsRAsxWAJ4wSF3yyrNI/XIWw6FXX05QCQFnRQCgkL9u
aStc2htFytY++OGHAYGXt8k=
=7Cun
-----END PGP SIGNATURE-----

--------------enigD05D4EDE71A53430B282FDF5--

--===============0941871425==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--===============0941871425==--