Re: [tcpm] TCP Long Options

On Tue, Jul 1, 2008 at 10:20 AM, Joe Touch <touch@isi.edu> wrote:
> It might be worth reviewing the discussion on the TCP-LO when it was
> previously presented, and provide a summary to the group as to whether
> anything has changed.

Good point, although I am probably omitting salient points which I
missed when reviewing the archives:

1. It's a "non-optional option" / it's another 4 bytes of bloat

Referring to the requirement that the LO option be included in every
packet. This requirement has been removed for implementation reasons
(it's very good to have a single fast path), but that also addresses
this. (However, the LO option is still required to be the first
option, if present and DO is required to be set to 6 in this case. I
reasoned that it was still best to remove extra degrees of freedom
about where to put it / how to set DO)

2. Some options can't be included in SLO

This is still correct. There's no good way to negotiate some options,
like MSS, if not included in the SYN packet so they cannot be moved to
the SLO option. The draft doesn't discuss this, and possibly it
should. Thinking about it, I might suggest that only options
explicitly defined to be SLO compatible should be included in the SLO
space. At the moment, that list might include just timestamps.

(Consider a SYN with MD5: LO (4 bytes) + WScale (4 bytes) + MSS (4
bytes) + SACK perm + TS (12 bytes) + MD5 (20 bytes) > 40 bytes - so we
can't even advertise LO in this case if we include TS in the SYN)

3. Three SACK blocks is sufficient

This is probably true for the vast majority of the time. However, auth
options esp reduce the number of possible SACK blocks when timestamps
are included as well. So, although extra SACK space is probably a
waste in packets with just a timestamp option, it can have it's uses

4. We could squeeze the options better

Several suggestions concerning making better use of the options space
were suggested like a binary flags option where timestamp permitted
and SACK permitted could live, or making the timestamp option smaller
in SYN packets. This would have been a great idea before these options
were deployed, but there's really no good way to transition now that
they have wide acceptance in their current form.

However, possibly we should change that by defining that binary flags
option right now and make LO the first user. If there's general
acceptance of this, I'll happily write the drafts.

5. Other methods of extending the option space

For example, making DO 5-bits wide or defining a scaling options for
DO. None seemed to gather widespread acceptance.

6. There's no need / we're not running out of space

Fundamentally, this objection is unaddressable by a long options draft
:) I suggest that there is a need in the case of TCP-AO/MD5 to include
SACK blocks. Additionally, the lack on long options hampers
experimentation. Personally, I'm pushing this because I want to
include an ECDH key exchange and need the extra options space. Others
have certainly needed the same thing and by specifying it we can aid
experimentation and encourage future TCP work which might not have
happened otherwise.

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm